Maintaining and Deploying Two Versions of an Application Simultaneously

Question

I have a C# WinForms application in Visual Studio 2010 that is used by two different customers. The basic functionality of the application is the same for each customer, but certain lines of code (names of stored procedures, resources, certain behaviors) are different between versions. So far, I have kept the application in the same project, and used preprocessor directives when building/publishing to switch between which deployment to use. However, the scope of the project has grown to a point where this is no longer feasible.

Since so much of the code is shared, I'm trying to avoid duplicating source code files. I'm wondering what the best approach is to maintaining an application that requires different versions to be deployed simultaneously.

Preprocessor directives should not be used to handle branches. — Ryan Gates, Nov 29 '12 at 19:12
Agreed. This began as a small, in-house application that external customers expressed interest in, so we needed a quick solution for separation. — WickerPopstar, Nov 29 '12 at 19:52

score 4 · Accepted Answer · answered Nov 29 '12 at 19:01

Use interfaces to define your classes. Having an interface means that you can have multiple implementations of the same interface, one for each of the clients. This will require you to analyze your existing codebase and identify logical separations in your code where these interfaces can be defined.

You then have the ability to load an interface as needed based on the client. You could, for example, do this via configuration. Based on a configuration value you load Implementation1 or Implementation2. There are many, many ways to accomplish this particular bit. You should read up on dependency injection, inversion of control and have a look at tools like Ninject, Autofac, Unity.

It may actually be difficult at first considering how you have been using preprocessor directives but seeing as how your application is growing, you will need this refactoring to happen. Keep in mind that if you do not do it now, this refactoring will be a lot more expensive later as your application becomes more complex.

I had hunch it was an architecture problem, and thanks for the terminology (dependency injection, IOC, etc). Those were the terms I was missing when searching for a solution. — WickerPopstar, Nov 29 '12 at 19:49

score 2 · Answer 2 · answered Nov 29 '12 at 19:02

The different functionality should be a part of the application's architecture. If you need different functionality for different customers, abstract it away - create an interface that wraps up the behaviour, then implement it in two different ways in two different assemblies. Then (depending on your deployment mechanism), you can ship your app with either one DLL or the other. To avoid having to recompile, add references, etc, you can use Dependency Injection frameworks such as Ninject, Castle Windsor, MEF etc. That's a "plugin-like" architecture, if code is sufficiently different.

If you're talking about text, colours, basic differences, they should simply not be hard coded but instead data-driven. If your app is internet-connected, it could download the appropriate settings when the user logs in. Else, something to indicate the text/colours/behaviour could be put in a config file specific to the customer. You can use config transforms to simplify that process.

The basic differences are already data-driven, thankfully. It's primarily functionality. I'm unfamiliar with those frameworks, but this application uses a ClickOnce deployment. Does that change how those frameworks are implemented? — WickerPopstar, Nov 29 '12 at 19:57
I have exactly the same situation in my project. Ninject, other DI frameworks will work, but we dynamically download DLLs from a URL after the app is installed: otherwise every customer gets a DLL with all the other customers' logic in their own installation. It doesn't change much, just that you want to load assemblies from a URL rather than disk. Or what you can do it from disk anyway:) — Kieren Johnstone, Nov 29 '12 at 20:42

score 0 · Answer 3 · answered Nov 29 '12 at 19:03

You might be able to separate some of the differences by using resource, configuration, or property files of some kind. By this, I mean you store some kind of value in the file, such as the name of the stored procedure to use in a particular situation. Then your code reads the name from the file and runs it. You can change the values in the file without needing to rebuild your code for each deployment.

Maintaining and Deploying Two Versions of an Application Simultaneously

3 Answers3