Problem: Multiple solutions using shared dll's can cause havoc when individual solutions are retracted.

Example: You have a web part helper dll used by all your web part code. If you retract a solution containing a reference to this dll then the SafeControl entry is removed from the appropriate web application and all your web parts start to fail. Or even better, the dll is removed from the GAC altogether.

Solution: I don't know? You tell me.

4 Answers 4


When you have common/shared components, like the helper DLL you talk about, that get used across multiple solutions within you organization. My recommendation is to package these up as a 'framework solution' that is deployed to the servers indendently of the 'feature based solutions'.

This way you 'feature solutions' are developed in the knowledge that the 'framework' is always available.

SharePoint always will retract/remove what you added in a solution package, unforunately it does not have anything built in to detect shared components.

  • I have a seperate feature solution which deploys my helper dll. I use WSPBuilder add in for VS 2008 to build my WSP. The WSPs for each web part solution will try to inlcude the helper dll too as it is referenced in the project. When these are retracted they then remove the helper dll and SafeControl entry thus killing all the other web parts deployed within other solutions. Commented Oct 8, 2009 at 11:43
  • One way to avoid this is to not add any code into the WSPBuilder solution project. Use WSP builder to do the packaging only. I add a post build event to my DLLs to copy to the required 80 and GAC folders in the WSPBuilder solution project. Again these are hacks really, but seem to work. Not sure if you can set copy local to false and see if WSPBuilder ignores them? Commented Oct 9, 2009 at 10:41
  • Why struggle with WSPBuilder ? I'm using STSDEV. Edit the SolutionConfig.xml and I can decide what dlls to add and where (GAC/Bin). The requirement is to have that helper dll in the debug\bin when doing a DebugBuild. Commented Oct 13, 2009 at 21:39
  • Woody - That seems like a great hack. I had not thought of WSPBuilder as just a packaging tool, but of course thats all it really is. Commented Oct 16, 2009 at 8:49
  • You could also use the -excludefiles option of a project-specific WSPBuilder.exe.config to list the DLLs you don't want included in your WSP file. Then you can still reference those DLLs in your project, and still use WSPBuilder to build a WSP for that project directly.
    – ngm
    Commented Mar 1, 2011 at 15:02

The method I use is to merge all assemblies into one using ILMerge as part of the build, before packaging

This make its bulletproof as then its impossible for someone to somehow remove dependant assemblies.


Yes, That's a common issue in SharePoint deployment. My Solution is to change the version number for helper dll-s. So even you have multiple helper dll-s in GAC that should not be a big issue. Tip:SolutionInfo

  • Do you hit problems with safe contols in web.config, or do you end up with lots - one for each version? Commented Oct 9, 2009 at 10:42

We assign each shared Assembly to a single WSP file. We then use feature dependencies to describe whether any one is using the shared component and have the rule that shared dependencies cannot be uninstalled if any active features depend on it.

The difficulty is in convincing everyone to follow the rules.

Teams tend to copy and paste Assemblies into their own WSP files or uninstall any WSP files they deploy without paying attention to the rules.

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.