Application project structure question

I would like to ask you what experience you have with developing and deploying one application that in general has some standard features, but the application can also have customer specific features.

For example:

1. Customer 1 have the standard features but also want a search function.
2. Customer 2 have the standard features only.
3. Customer 3 have the standard features and also want an employee calendar.

How would you solve this?

Would you have one project where you deploy all the application from and then have some kind of config file to determind which features are avaliable in the specific application?

Would you have one project for each customer? This is how I'm doing it now, but the problem here is that if there 开发者_运维百科are bugs that need to be fixed in the standard features I have to fix them in every project.

Any other suggestions are very welcome.

The application is developed in Delphi and C#.

My company solves that problem by giving all customers all features. This keeps development simpler and allows us to spend more time working on improving the product and not have to spend time dealing with the complexities of optional features.

We sometimes meet mild resistance from clients who want a cheaper version with less functionality but that's never been a sales problem.

On the other hand if you sell clients cheaper less functional versions, they are liable to try to get away with these cheaper versions. This can then lead to them not liking the software as much they should because they bought the cheap crippled version. I strongly believe in getting the best product possible to the user.

This advice may not be appropriate to your personal situation, but you did say that any opinions would be welcome.

One version per customer is not a good idea, IMHO. It will stuck your sales one day or later.

Better let all features be released to all customers, i.e. just maintain one software, but locked by a password, for instance. You can give a unique licence number at the software installation in order to identify the customer (put its name in the licence), then compute some passwords according to this licence number, to unlock some features, on request - when paid. This password can be easily automated via a web site, with minimal cost for you.

Or you can also let all functions available for testing, but lock the printing or the saving - just to let the customer think about spending some money to have this "nice added feature".

Sometimes, having all features tend to create a "Gasworks" application. You'll probably need a separate setup application, to customize the application to your customer's needs. Worth thinking about this architecture.

Even with a revision control, multiple versions are a nightmare to maintain: for instance, just back-port all hotfixes to a previous version takes a lot of time. If you don't have to (because of regulatory purpose / certified versions e.g.), don't "branch" your software.

No definitely do not have one project per customer, you could have one solution per customer where you agregate all projects given setup need.

Just to give you in an alternative to plugin architecture, which is right way to go, but also usualy fairly complex.

Option1.

1. Put common functionality in main project (Core)

2. Additional stuff like calendar put in separated DLL projects ( one per functionality)

3. Create VS SOLUTIONS, where you agregate all projects for specific setup + Core. So customer1 will have Customer1Silution with Core and all additional projects he need, customer2 its solution with Core and its additional stuff.

Option2.

Have one big setup for every one and based on its configuration/license enable/ disable access to user to a additional functionality.

Depends on your resources like time, experience, people you work with, clients , you can chose an option more appropriate to you.

1 plugin based: may be the best one but it, complex and it will take a time you become familiar with it, if you never did before something similiar.

Option 1 easy and fast, but if the clients quantity and configyration become defer you will jump into scale problems.

Option 2 is an average between those two, but keep an eye on your setup dimension.

Considering tha fact that you refer projects and nit DLLs in your solutions, if you fix a problem in Core in one solution it will affect also all other solutions.

you have several options:

• put the "standard features" into separate module(s) which can be used/linked by the other versions
• use a "plugin-architecture" to load the optional features dynamically

In addition to what others have said there is another option: Conditional defines.

With conditional compiling you can wrap feature specific code with IFDEFS (IFDEF EmployeeCalendar, IFDEF SearchFunction...). Then for each client you copy the project file only and set the conditional defines according to features you want to include.

If a client wants/pays for additional feature you just add it to Conditional defines in that client's project file.

This is similar to the modules approach (BPL/DLL) but avoids the added cost of having to deploy/manage extra files. The drawback is that the feature set is fixed at compile time.

With BPL/DLL you could dynamically load additional modules at run time, but if that is not important in your case, then Conditional defines might be a good choice.

Of course if your features are not easily separable then you can end up with a lot of IFDEFs in the code, but then your problem is clear separation of features, and it would be the problem with modules too.