0

In one of our projects, we adapt parts of our software to specific customer requirements (logos and about boxes, for example). Each of the customers gets its own release which does not include specifics of another customer. Currently this is implemented with preprocessor directives and separate build configurations for each of the customers. However as the number of projects in solution is increasing, it is getting hard to maintain these configuration (and it is getting messy, too). In essence, all configurations are "Release" builds named "Release X", "Release Y", "Release Z". They are all the same, except one preprocessor directive for distinguishing between customer builds (for example, to use proper application icon). Furthermore, the configurations must be the same, to provide consistency across builds.

For the build on build server I can create a MSBuild script, set the "DefineConstants" property and build the solution in "Release" configuration. What about doing the same in Visual Studio? I want the developers to be still able to run builds for specific customers locally (for debugging / testing purposes), but I really want to get rid of configurations for specific customer. Because if I change something in release build, it is not propagated directly to customer specific builds and I have to do it again for every one of them.

Any ideas how to simplify these builds?

Zvonko
  • 363
  • 2
  • 19

2 Answers2

0

I don't fully understand all of the things you are needing to separate by customer but I have a similar challenge and here is how I solved it:

1) If there absolutely positively have to be code differences then you can use preprocessor directives to separate the code.

2) You can run a build helper in a Pre-Build Event that writes a header file with customer specific definitions.

3) Use WiX/heat.exe to assemble any customer specific build artifacts like graphics and such.

Greg Prosch
  • 998
  • 2
  • 9
  • 16
0

Let me explain, what I did to achieve my goals. I use preprocessor directives to separate the code. The trick is where they are defined. Under VS I load them from configuration file, on automated builds (TFS) they are set in build script. Now I only have two project configurations, Debug and Release. Everything else (customer specific builds, code analysis build, etc) is controlled by preprocessor directives. For the server build I have separate .proj file which sets the appropriate constants and builds the .sln file. Each .csproj includes additional build script (via Include statement) in which I first override project properties to ensure all projects have the same settings (i.e. for Debug builds I set DebugSymbols=true). In this script I also load the preprocessor directives from the file before the compilation of source is started.

Zvonko
  • 363
  • 2
  • 19