This is an argument that often get poked in online forums (social.microsoft and the like) but no one seem to have a clear understanding of all the issues, so I am posting here. Also notice that the following is from a pure technical viewpoint, avoiding on purpose discussion about any legal implication dll embedding may have.

The problem is easily summed up: most of the time I work on "on commission" custom solution for clients that use multiple competitor agencies to externalize their SharePoint development. This means that most of the time I have very little control over the farm environment, yet I found myself constantly having to use external libraries I often can't avoid or supply myself.

Simple example: think of entity framework. All the competitors use it. Result: n solution try to deploy the same dll and this become a "warfare" scenarios with no real ALM plan - every application can potentially destroy all the others one when retracting, by removing a single dll everyone use. This could be avoided if the libraries where provided by special ad-hoc solutions that just do that, but not every client seem to accept that.

For that reason, I was considering as at last option to use dll embedding-as-resource to avoid deploying dlls to the gac in the most desperate situations. Probably many of you know Costura.Fody or others dll embedding plug-ins, but any attempt to use it in my test have failed. It seem like SharePoint overwrites the handler dll embedding solutions use to handle the AppDomain.Current.AssemblyResolve event and provide custom resolution, but I can't find any source confirming this.

For this reason I am asking about any success story you may have about using dll embedding on SharePoint or procedure you are using to achieve that. I am also open to any alternative you may have that could be used as an alternative to provide better control in environments like the ones I described.

PS: I already have considered using bin folders instead of GAC for dll deploy, but my clients have the habits to use "one for all" web applications, so it wouldn't provide much help.

1 Answer 1


I recently had some more time to review this old issue and try to give an actual answer to my question.

After some more testing, I was able to determine that (when used on a SharePoint 2013 farm):

  • Using Costura.Fody to embed libraries works when deploying libs to the BIN folder and fails if the lib are deployed to the GAC.

  • Module Initializer works for assembly deployed to the GAC. This was tested with the Costura Module Initializer nuGet package.

  • even when assemblies are deployed to the bin folder, Costura isn't able to enforce dll version specificity when resolving references. This means that if multiple solutions in the same AppDomain use the same library with different version, the first one to get resolved will then be used for all sub-sequential resolve attempts

I was also able to point out some sources stating than AppDomain.Current.AssemblyResolve won't work for GAC assemblies, but sadly no official Microsoft one.

Reference: AssemblyResolve for GAC'd Assemblies

While on SharePoint 2013 the removal of the need for custom CAS policies definition has made BIN folder deployment a wider option, using Costura to embed reference still would leave us open to the DLL version problem. Since the primary reason to adopt Costura in the first place was to make project use a "local" version of what would be normally a shared library, risking usage of a different version of the assembly is a mayor issue.

As now, the solution is not fitting my needs, so I am abandoning it. I will do further experiment to see if the present issues may be somehow circumvented and will post back my finding if any new option arises.

Update: I am currently considering to switch from dll embedding to dll merging. I have found out that using ILMerge and a nuget package called "MSBuild ILMerge Custom Task" I am able to merge any "external" signed library reference to the main solution assembly. My current prof-of-concept solution shows that ILMerge can be used to have multiple solutions deployed to the same farm and web application provision multiple web parts on the same web site page each one using a different version of the same class library project.

I will do some more test and update the post with my finding. As now, it is probably worth considering library merging as a solution over dll embedding (something that seems to break apart very easily in many real-life scenarios). I will also double check about the legal implications - if any - of dll merging over embedding (does it count as an unlicensed modification of the original merged libraries?).


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.