Unexpected DLL in a WSP package
When you are building SharePoint projects based on a framework/base approach you'll find yourself in the situation where you want to use specific modules from one of your base projects. The correct way to do that is to ensure that the required features are activated on the farm / web application / site collection / site that provision you those modules. Visual Studio however lets you reference those modules individually in your features. Although this DOES WORK and your code will run fine, it will result in a maintenance nightmare. Doing this will put the DLL of your base project in your WSP. This results in the actual version of the DLL being baked into the WSP of the solution that is referencing the modules of another project. Why will this cause a maintenance nightmare?
Imagine the following scenario.
Environment
- Internet Farm One
- Internet Farm Two
Installed Solutions
- Internet.wsp
- MyNewSolutionBasedOnInternet.wsp
Scenario 1 (Internet GoLive)
The internet solution will be released (everything will go fine)
Scenario 2 (MyNewSolutionBasedOnInternet GoLive)
The MyNewSolutionBasedOnInternet will be released (everything MIGHT go fine)
This scenario will go fine as long as no development on Internet v2 has started. As if that is the case the deployment will add the newest Internet.dll to the WSP resulting in the new dll being deployed to the production environment which might give unexpected results (code referencing controls that are not on the usercontrol etcetera).
Scenario 3 (Internet v2 GoLive - MyNewSolutionBasedOnInternet v1 Live, development stopped)
The new Internet version will be released (everything MIGHT go fine) The MyNewSolutionBasedOnInternet version 1 is already live and development has stopped. The WSP's for MyNewSolutionBasedOnInternet are ready to be redeployed.
This scenario will go fine as long as there is ONLY an upgrade happening of the Internet solution. If you have a setup with two production environments that are switching chances are that you are going for a content database copy and a full solution reinstall. In that case Internet.wsp (v2) will be deployed before MyNewSolutionBasedOnInternet and the old DLL will overwrite the new DLL. If you then consider a scenario where your IT guy has to deploy several solutions based on the Internet codebase it's gonna be a pain figuring out where things are going wrong and why there is an old version of the dll.
Scenario 4 (MyNewSolutionBasedOnInternet downgrade)
The downgrade WILL FAIL. If problems are identified on the day of the production release and you decide to go back one version you will actually be removing the Internet.dll and you will be breaking the internet based solutions as well.
I hope these are enough scenarios for you to consider before you decide to go for the module sharing approach. Just compare it on how you work with SharePoint out of the box. If you need something, you make sure that the features deploying these items are activated.