Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top