CODEWITHSUNDEEP
sharepointweb-parts
Antonio Ciolino
Antonio Ciolino

Reputation: 556

Perferred practices regarding Sharepoint Web Parts in a single Visual Studio project?

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.

Upvotes: 2

Views: 193

Answers (2)

meccaneko
meccaneko

Reputation: 136

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].

Upvotes: 1

Nat
Nat

Reputation: 14305

Your list of pros and cons are pretty good, but they are predicated on webparts that are entirely independant. I find that I am often creating one or more webparts that are inter-related and thus share some code. There is then an immediate benefit to having these webarts in a single solution.

In practice both of your con's are not really an issue. It would be similar to worrying about re-releasing an entire ASP.NET web appliction when all you want to do is change one web form.

So, with the Cons out of the way, thedecision become one of convenience. What is the most convenient grouping of these webparts. Some easy distincations are about the target of each webpart e.g. farm vs solution. Further easy delineations are around which particular sitecollections webparts target.

All in all, I imagine it will be easier to decide to group the webparts than it will be to decide into which groups.

Upvotes: 2

Related Questions