How to program three editions Light, Pro, Ultimate in one solution

Question

I'd like to know how best to program three different editions of my C# ASP.NET 3.5 application in VS2008 Professional (which includes a web deployment project). I have a Light, Pro and Ultimate edition (or version) of my application. At the moment I've put all in one solution with three build versions in configuration manager and I use preprocessor directives all over the code (there are around 20 such constructs in some ten thousand lines of code, so it's overseeable):

#if light
//light code
#endif
#if pro
//pro code
#endif //etc...

I've read in stackoverflow for hours and thought to encounter how e.g. Microsoft does this with its different Windows editions, but did not find what I expected. Somewhere there is a heavy discussion about if preprocessor directives are evil.

What I like with those #if-directives is:

• the side-by-side code of differences, so I will understand the code for the different editions after six months
• and the special benefit to NOT give out compiled code of other versions to the customer.

OK, long explication, repeated question: What's the best way to go?

Answer 1

i would suggest to create the basic classes and features as normal, but to allow override for that mathods that would be edition-specific.

then you create a light/pro/ultimate edition assembly that overrides that methods.

then you need a factory, that instanciate the correct overriding types depending on the edition.

here you could work with the internal-accessor and make the code assembly internal visible to the edition-assemblys

Answer 2

I'd be tempted to manage the differences during runtime with different licences, and enable/disable features using that configuration. Why ?

1. you only have to build one deployable.
2. you can unit test this much more easily, rather than build 3 versions and test this.
3. users can upgrade and simply be sent a new licence. They won't have to upgrade/reinstall.

You have to weigh this up against your concern for distributing a solution that your customers haven't actually paid for (and can simply enable via an appropriately secure licence key).

Answer 3

My first thought is to split your software into various modules (projects/assemblies), and then create three different setup projects in your solution, one for each version. In the setup, you only include the modules you need.

You will loose the "side-by-side" code, but IMHO this just creates complicated methods, instead of maintainable code. Use extension methods, if you want to provide more functionality for a type, or derive classes.