While working with SharePoint Solutions one may come across the following scenario.
Scenario
You have a project containing:
1. Master Pages
2. Content Types
3. List Definitions
4. Web Parts
5. Workflows
6. Event Handlers
How many WSP files you have to make?
· Single WSP having all above components
Or
· Multiple WSP like below:
a. Master Pages WSP
b. Content Types WSP
c. List Definitions WSP
d. Web Parts WSP
e. Workflows WSP
f. Event Handlers WSP
The advantage of Single WSP is that we just needed single WSP deployment.
The advantage of Multiple WSP is that a small change only requires single WSP deployment.
What is the optimized path?
To come to a conclusion one has to go through the following thoughts.
What are the reusable components?
We have to find out whether Reusability of a WSP across projects exists? If so we need to separate that component as a separate WSP. This makes deploying only the needed WSP to other projects without including the unnecessary files.
Are we selling components?
If we are on the market to sell the web parts, then we need to think of separating web parts from the rest. A separate WSP can be sold to the market.
Is the project very large in size?
If our project runs to multiple modules, it is good to have multiple WSPs. Here each department can play with their own module features.
What is the Development overhead?
Clearly developer will get over-killed in going with multiple WSP route. He or She has to maintain a list of changes made so that only the needed WSPs can be send for deployment.
What is the Testing overhead?
If we maintain multiple WSPs without a reason & still the Testing effort remains same, there are no advantages of going with multiple WSPs.
For example: A small master page change only requires a smaller WSP to be deployed. But this small change also needs testing of other content types, web parts & so. Here the testing effort is not reduced.
What is the Administration overhead?
SharePoint Administrator has to go through multiple WSP deployment. In cases were a dependency WSP is not properly deployed there will be chaos. The overheads increase exponentially in case of multi-server topology & caching cases.
What is the User overhead?
Multiple WSPs results in multiple features. SharePoint User has to go through multiple feature activation & deactivation to get the total solution running. This can be awkward.
Alternative Thought
Let us think how we were deploying .Net Assemblies.
A .Net assembly have multiple classes. A method in a class changed. We deploy the whole Assembly!!
Similarly, we need to think WSP as a single unit of solution.
Conclusion
Following would be the conclusion factors:
· For single project single client scenario, go for single WSP
· For multiple project scenario, extract the reusable components as separate WSPs
· For multiple client scenario create WSP based on deployable components
Please collect inputs from all stake holders involved:
1. Developers
2. Administrators
3. Testers
References
http://msdn.microsoft.com/en-us/library/ee231544.aspx
Summary
In this article we have explored whether to go with Single or Multiple WSPs. I hope this will be helpful in real-worlds scenarios.