I have a site which has a number (20 or so) web parts. Each part is it’s own Visual Studio solution. I’ve been asked about consolidation of these web parts into fewer WSP’s.
What I am wondering about is what the practices have been around this problems. I can see pros and cons to each aprpoach:
PROs:
– Less WSP files to manage
– Consilidation of common or similar functionality into a single
solution
– Easier to find what you want to get to – less projects
CONs:
– Changing one web part requires redeployment of the entire WSP – which means all other, untouched web parts (is this true?)
– Risk with deploying code that didn’t need to get touched
Seems that the pro’s outweigh the cons, but those are some pretty big con’s.
UPDATE
Decided to go with merging projects, but for a slightly different reason than listed: namespaces.
Overall, these projects were all standalone, though they were part of the same “site” offering. However, nothing was ever namespaced.
So, the decision was to namespace projects with a company.application.funciton.feature style. Once this was done, it seemed sensical to merge several of the projects into namespaced .NET solutions; and therefore in many cases to simply make the assembly that is deployed the “root” name.
For my 2c worth I find it simpler to use fewer solutions. You will make your SharePoint Administrator happier too as it will take less time to deploy changes.
If you are using some form of source control mechanism you can easily track changes to code which can help with one of your listed CONs [Risk with deploying code that didn’t need to get touched].