0

Just a quick question about proper helper dll dev. I want to deploy a set of classes in a helper dll for a bunch of features to use. I remember back in 2007 I had to create a class and compile, then a separate sharepoint feature to house the dll. I'm wondering if that is still the proper way of deployment or if I can simply create an empty sharepoint feature and create a helper dll in that feature and deploy.

Any thoughts?

Sorry guys for not chiming in on this, been away. I simply wanted to know what the best practice was for deploying helper style assemblies that multiple SharePoint solutions reference. Yes I can simply drop that custom assembly into the GAC manually on each server in the farm, but I wanted to know about a more automatic way of performing this task.

In SharePoint 2007 I would simply piggyback a custom assembly in one of my site wide feature solutions. Creating the “GAC” folder and let WSPBuilder do the rest. I just wanted to know if it was the same process in SharePoint 2010. If I add the custom assembly in the Package definition declaring it as a safe object for each of my SharePoint solutions that need to reference this helper dll it of course is deployed correctly with no fowl. However if I decide to deactivate and retract one of those projects with the reference it in turn removes it from the GAC orphaning the rest of the projects that have the same reference, causing everything to grind to a halt until the helper dll is reinserted into the GAC.

Any thoughs?

Improve this question
3
  • Just deploy it in a solution file? Why would you wrap it up in a feature in 2007 or 2010 unless it was actually a feature?
    – Kit Menke
    Commented Feb 22, 2012 at 19:47
  • Oh.. feature dependencies perhaps? That why?
    – Kit Menke
    Commented Feb 22, 2012 at 19:50
  • Here's another reference to the topic. link
    – Patrick
    Commented Mar 6, 2012 at 19:26

2 Answers 2

Reset to default
2

To add an existing assembly

Open the Package Designer. For more information, see customize a SharePoint Solution Package.

Click the Advanced tab.

Click the Add button, and then click Add Existing Assembly.

The Add Existing Assembly dialog box appears.

Click the ellipsis (ASP.NET Mobile Designer ellipse), and select the assembly that you want to add. We recommend using a relative path to the selected assembly for portability purposes.

For the Deployment Target, click GlobalAssemblyCache to deploy the assembly to the global assembly cache, or click WebApplication to deploy the assembly to the WebApplication folder on the SharePoint server.

To add an assembly from project output

Open the Package Designer. For more information, see How to: Customize a SharePoint Solution Package.

Click the Advanced tab.

Click the Add button, and then click Add Assembly from Project Output.

The Add Assembly from Project Output dialog box appears.

Click the drop-down menu, and select the source project that you want to add.

For the Deployment Target, click GlobalAssemblyCache to deploy the assembly to the global assembly cache, or click WebApplication to deploy the assembly to the WebApplication folder on the SharePoint server.

See this post for more details

Improve this answer
6
  • Eh... I think he is asking about deployment rather than how to reference an assembly?
    – Kit Menke
    Commented Feb 22, 2012 at 19:46
  • hmm.. if your reference assemblies in the package that contains features, they are deployed to the GAC in time when the package is deployed to the site. am I right? Did I understand question correctly?
    – Alexander
    Commented Feb 22, 2012 at 19:57
  • Right.. I think he is asking what the best way to deploy those assemblies? I think there are really only two good choices: solution file or feature.
    – Kit Menke
    Commented Feb 22, 2012 at 20:01
  • @KitMenke, how could it be done by feature? I have never seen this approach. I always think that assemblies are included in solution file (package).
    – Alexander
    Commented Feb 22, 2012 at 20:08
  • Yeah sorry... I was assuming the feature would be in a solution as well. It is just the extra step of putting your helper DLL in another feature.
    – Kit Menke
    Commented Feb 22, 2012 at 20:14
0

Any helper dll have to be deployed as a separate wsp package. Otherwise, after wsp package retracting, you will miss all the solution as well as the dlls in that solution.

So, for every common-lib you have to create dedicated wsp package and include needed dll in that package. After, you make an assembly reference in other "my solution" wsp packages, but don't include common-lib in package and don't deploy common-lib in "my solution package".

Hope, this will help.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.