R – Should I keep solutions and features in a 1-1 ratio

deploymentsharepointsharepoint-upgrade

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?

Best Answer

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.

Related Topic