I'll use my blog for a bit of fishing for advice and guidance on an issue that's been bugging me.

We've been moving towards using strong names on all of our assemblies. The benefits are obvious, and it's a must before we deploy to clients out in the wild.

The problem is that we have several different processes running, each with its own app.config or web.config file. These config files contain references to custom configuration sections, whether they're application configuration, Enterprise Library extensions or whatnot. Seeing as my DLLs are signed, I have to use the fully qualified assembly name in all my references. This means that in a nightly build scenario where my version number is bumped continuously, I have to change 5-6 references in 5-6 configuration files with every build.

Doing this kind of string manipulation on a large scale scares me, since it can break, or we miss something. I've tried using <assemblyBinding> and <bindingRedirect> directives, but they require a specific version to point to as well.

I'm sure I'm not the first person to encounter this problem. What are the solutions that you use to bypass this? Scripts as part of the automated installation? Moving all configuration sections to a separate assembly whose version is static? What's the least painful way to manage this?

5 Comments

• Pawel Pabich said Thursday, December 20, 2007 1:41:21 PM

  We build all our projects using nant scripts and we have a separate target that looks up all assemblies that we are interested in and updates web/app configs with the correct versions. From my point of view string manipulation is not scary as long as it's automated.

• Buzza said Thursday, December 20, 2007 4:08:25 PM

  You actually should NOT bump up the version number (i.e. MOSS SP1 didn't) of the assembly version number. You should change the file version number (not used in the strong name) and the will solve all your problems. Only bump up the version number of the assembly if you need to have both versions of the DLL running on the same machine (i.e. SPS 2003 -> MOSS 2007 went from 11 -> 12)

• Omer van Kloeten said Thursday, December 20, 2007 5:30:25 PM

  How about publisher policies?

• Avner Kashtan said Wednesday, January 2, 2008 9:54:47 AM

  Buzza: Thanks for the advice. That's the approach we're now taking - FileVersion is bumped on every build (continuously!), while the assembly version will be bumped only for major releases. Thanks again.

• tipsforcdevelopers said Tuesday, August 16, 2011 6:07:26 AM

  Hi, I have exactly the same problem. But for our applications we will the Assembly Version and File Version have the same number. Because when these numbers are not equal it is confusing. But we have also a reference to a strong named assembly in the configSection element and after each build we have to update a large number of configurations otherwise the application can not be executed succesfully. May be some one has a solution? For now we leave the 'version' part in development process.