Visual Studio 2008 Configuration Manager
-
Hello!
I've been struggling with the Visual Studio 2008 Configuration Manager. Its a real pain to use for complex solution/project configurations. My current solution contains 52 projects and 46 (!) different configurations. The number of configs keeps growing with each client version and maintaining them is becoming a real issue.
So, my question is that is there an alternative for the default Configuration Manager or should I write some script or VS add-in to ease my pain? Or is my initial approach using the build configurations for selecting/building between different client versions the main source of problems?
-
46 configurations is too many.Is it that you have 6 "base" assemblies and 46 client plugins... give or take?
If so, I'd create solution files for this purpose instead of using configuration.
-
@Alex Papadimoulis said:
46 configurations is too many.Is it that you have 6 "base" assemblies and 46 client plugins... give or take?
No client specific assemblies other than resource dlls. The main project is an ASP.NET project and the rest are business logic, data access, tests, etc. The only thing changing is the configuration files for the client versions (Spring Framework configs mainly) and the correct resource assembly gets copied to the web applications bin -folder.
So what I've done is that when I select build config "HugeCorp" and build the solution the main project just copies different set of configuration files, css files, etc to the web application sub-folders with the HugeCorp specific resource dll in the projects pre-build event.
Also I have "HugeCorpStage" config which is used when building in CruiseControl.Net. So there are two build configs per client.This wasn't a problem with just a few different client versions but now we have 23 clients. Otherwise this has worked quite well but the increasing number of clients has made the build configuration management a real pain.
Any alternate solutions for this since I'm clearly looking the whole problem from a completely wrong angle and turned this in a major WTF :-D
-
That does sound messy.
From a configuration standpoint, it sounds like the classic "Pre-Build Plugin Architecture" problem; you have a baseline application and a "Plugin" is applied (css, resource dlls, etc) applied "in house" before deployment "to the field." IOW, the plugin is an integral part of the build; it's not something designed to be swapped by the end user. What's unclear is whether a baseline update triggers all clients to be updated, or if they are updated on an as-needed basis. But, that doesn't really matter from a build/config standpoint, since both have similar solutions.
Tossing in staging deployments makes matters even more tricky, since your testing level (currently, only Staging it seems) is a multiplier of complexity. Adding in more testing environments (UAT, QA, etc) makes life all kinds of worse.
Unfortunately, there's no easy* solution; you're going to have to go outside of Visual Studio to simplify things. The first step is to re-evaluate your build process to remove duplication. You don't need two build configs per client; figure out a way to programmatically modify project files when your build runs so CruiseControl will be happy. Next, try to isolate the plugins from the baseline application. Think of each plug-in as a micro-app in and of itself, not as an integral part of your basline application. Reason being... imagine what life would be like with 10x clients. It'd be a great problem to have, but whooooa momma would it be a problem to try all that in visual studio.
* unless you want to consider a vendor product; BuildMaster was designed to solve build/deployment challenges like this
-
I agree with Alex on this. While I don't have that much experience with ASP.NET deployment and packaging, I would try and move this from build to packaging. For instance, if you could somehow seperate this into a dll or other shared resource, then you could have a different dll for each client. Then when you package for the client it is simply a matter of including the correct dll.
I might be oversimplifying some things here, but I think this should be doable.
-
Thanks for the info. This confirms that my initial approach wasn't the best solution for this.
I already started to looking into scripting the builds. I'll probably will go with MSBuild since I'm already using it with CruiseControl.Net.
Only problem would be when building/running the code from Visual Studio. Currently I can choose the appropriate client build config and debug it easily (Locally of course with local db etc.) and if I understood you guys correctly I would lose that option. This has been a real time saver. Or did I misunderstood you that I would only have one config for running locally? I'm a bit lost here as it would be great to have the possibility to debug the application with different client configurations.
Of course I could debug the web application by attaching to the IIS process but do I have any other options?
Alex, I'll have to check the BuildMaster out. Seems interesting.
-
This may be more of an architecture question, but...
If all your DLLs share a common interface, why wouldn't you specify which client dll you want to work with in your config file and dynamically load the correct one at run-time based on this setting?
