views:

81

answers:

2

Assume for a moment that you are creating a commercial product for SharePoint. This product will be offered in both Community (free) and Enterprise (pay) editions.

The code base for the Community edition is a subset with minor deltas all handled through (C#) #define statements. Effectively it's a single code base. The build process builds two solutions (each containing two features), one for each edition.

It should not be possible to install both editions in a farm at one time. The current business model offers the community/free version only for single server SharePoint farms. This is intended to support individuals and development scenarios.

The solutions include a variety of functional elements but currently no web parts. It is possible that one or more web parts may be included in a future release. Any approach that limits solution/feature contents is probably not the best idea in the long run.

To what extent would you reuse solution and/or feaure ids across the editions? Why?

+2  A: 

I would want people to be able to easily upgrade from free to full if they choose to do so.

Imagine the case of a web part - if you setup a few versions of the free web part, then unintall it and install the full web part then most people will want all existing instances to keep working but on the new web part

I think you would need to keep the solutionId the same for this to work.

You would also need to have the full assembly name the same (the file version can be different) or setup binding redirects.

Oh - and no breaking changes in your code of course.

Ryan
Thank you for the reply. Your logic about desired upgrade behavior makes good sense. The way the solution is engineered the upgrade behavior you describe can be accomplished with both approaches. Any other reasons to go one way or the other?
Jason Weber
Are you sure that if the SolutionId changes SharePoint will load the new web part in place of the old one where the users have already set it up? I guessed it won't and you will get the "Missing Assembly" error - but haven't had time to check.
Ryan
This is an interesting point. Web parts are bound to a strongly named assembly. As you suggest, I would have to check to see if there is an additional binding at the feature or solution level.
Jason Weber
+1  A: 

I would use the same id's and provide an extra feature to unlock the enterprise functionality. This feature contains the extra dlls, web parts, license keys, ... needed to unlock the Enterprise Edition.

I would make sure that the users can continue using your product after the upgrade without having to change their customizations.

W0ut
The point about making it easy to upgrade without 'losing' anything is key. The model of upgrading via additional features can be very compelling. This works very well for example for standard vs. enterprise search controls in SharePoint 2007. In other cases, such as an event receiver, this may require substantially more effort. Thank you for the reply.
Jason Weber