Multiple Sharepoint projects in one solution - how to package correctly?

Question

I have multiple Sharepoint projects in a solution:

• MySolution.WF
• MySolution.Webparts
• MySolution.UI

I also have some common code in a

• MySolution.Common

project. All of the aboe projects reference MySolution.Common.

I first thought the way to go with SP2010 is to add the MySolution.Common project output to all other Packages (via Package Explorer > Advanced > Add > Add Assembly from Project Output) - this way Common is deployed with all three Sharepoint packages (WSPs) to the GAC.

However doing it this way might lead to deployment conflicts as I might first build/deploy .UI and afterwards .WF - hence I deploy .Common twice. Sometimes Visual Studio has hickups with deploying it this way (not finding receiver assembly, randomly deleting other solution DLLs from the GAC).

How do you manage Multi-Sharepoint solutions? Do you have one project just to accumulate stuff from all other projects or do you reference external DLLs in every project and it will be deployed with every project?

Answer 1

In our working project, we have "Common" dlls too. And finally, we came to a "container"-project concept.

So, if I understand correctly, you have 3 wsp's but only for development reasons. It is much better for development to have many little projects, than one huge monster, isn't it? :) But for installation, better to use all-in-one approach.

And here is an interesting feature in Visual Studio SharePoint solutions. Actually, you can create completely empty SharePoint project in your solution, and include SharePoint items from all other projects in it. This way you will get all-in-one WSP.

For example, I created solution with 5 from-template projects in it: three webpart projects, one list definition and one workflow project.

Then, I created empty sharepoint project (named "MyProduct") for "container" purposes. Navigated to Package.package, and included all the solution items in it:

Then, I packaged the project, and observed the resulting MyProduct.wsp:

As you see, all the items are included. Same way you can add your Common.dll into the package. This solution works perfectly with your real project, and provides very good flexibility in development (actually, we have more than 30 SharePoint projects in our main VS solution - and only 7 wsps for deployment).

Third-party assemblies

A very important notice here!! Please, work very carefully with third-party assemblies, which can be used not only in your own WSP's.

Just for example, if your client installs NLog.dll to GAC with your WSP package, and after this for some reason he installs another WSP, also containing same version of NLog.dll, all will work, but... If he then uninstalls one of mentioned WSPs, the second one will not be working! Because, it will remove NLog.dll from GAC :)

Details on this situation and workaround for it are published at SharePoint Sandbox.

Answer 2

Our way around this is to use ILMerge.

The common assembly is merged into the other assemblies post-build, avoiding problems with different assembly versions (less of a problem in your case) and inadvertent retraction.