Question

I have a complex sharepoint deploy with multiple EventReceivers and Workflows.

I also have schema changes to existing lists, adding new columns of metadata and changing existing columns.

Should I package a single feature, eventreceiver or workflow, to a single solution, or should I put multiple features inside the single solution since they all work together?

One major reason I am asking is for future code upgrades. If the features are seperated, then an upgrade in one portion of code would not require a re-deploy of all the features in the solution. Is this something I should worry about or does the ‘stsadmin -o upgradesolution’ take care of any issues with the upgrade of a solution with many features?

Let me know if this makes sense to any SharePoint gurus out there.

Thank you,
Keith

Update: Looking at the website drax referenced, I found this reference site: http://msdn.microsoft.com/en-us/library/aa543659.aspx

This statement seems to put a large handicap on upgrading features in solutions:

Solution upgrade can only be used to replace files. You can add new files in a solution upgrade and remove old versions of the files, but you cannot install Features or use Feature event handlers to run code for Feature installation and activation. The following operations are not supported in solution upgrade.

• Removing old Features in a new version of a solution.

• Adding new Features in a solution upgrade.

• Updating or changing the receiver assembly for existing Features in a new version of a solution.

• Adding or changing Feature elements (Element.xml files) in a new version of a solution.

• Adding or changing Feature properties in a new version of a solution.

• Changing the ID or scope of old Features in a new version of a solution.

• Removing Feature elements (Element.xml files) in a new version of a solution.

• Removing Feature properties in a new version of a solution.

So… What can you do with a solution upgrade?

Answer 1

I would advise against splitting everything into multiple solutions. Maintaing that can quickly become nightmare. Try to structure your project, which should is used to create WSP, in same manner as 12 folder of sharepoint. Then you can use WSP builder, last stable version brings a lot of useful stuff.

Also i’ve not noticed any problems with redeploying solutions. According to this article and to my experience deployment of WSP takes care of synchronization between versions. So if you will add some new features they will appear and if you remove/change features they will be modified accordingly.

EDITED:

So I did some quick research on MOSS Updating topic. According to MS there are two ways of updating solutions:

1. In-place update
2. Incremental update

Basically, in-place update is standard way of updating. Meaning you are relying on build-in functionality as described in this (same document as posted before) document. Problem with this solution is that it lacks quite a lot of functionality (versioning, changing of ID’s of features,…).

Incremental update (this is how MS calls it probably) don’t rely on build-in solutions. That means it is up to everybody to implement it by themselves :(. What is even better I was not really able to find any guidelines for this approach. I suppose that approach you would like to take is example of incremental update (splitting project into many independent solutions).

Also note that Incremental update is not officially supported by MS.

So I don’t really know what advice should I give to you. Single WSP is more maintanable than buch of them, also if you are doing just some minor changes updates work perfectly. But if you need to make some bigger structural changes problems start to show.

I’ll probably wait and see if people with more MOSS expertise can say something about this topic.