Miscellaneous Debris

Avner Kashtan's Frustrations and Exultations

Seeking advice - strong names and config files

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?

Posted: Dec 20 2007, 01:48 PM by Avner Kashtan | with 7 comment(s)
Filed under: ,

Comments

Pawel Pabich said:

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.

# December 20, 2007 8:41 AM

Buzza said:

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)

# December 20, 2007 11:08 AM

Omer van Kloeten said:

How about publisher policies?

# December 20, 2007 12:30 PM

Avner Kashtan said:

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.

# January 2, 2008 4:54 AM

Bella Benedict said:

Pretty nice site you've got here. Thanks for it. I like such themes and everything that is connected to this matter. I would like to read a bit more soon.

Bella Benedict    

<a href="milanescorts.com/">milano escort accompagnatrici</a>

# March 25, 2011 12:47 AM

Joan Kuree said:

Pretty cool site you've got here. Thanks for it. I like such topics and everything that is connected to this matter. I definitely want to read more soon.  

Joan Kuree    

<a href="www.pickescort.com/">london escort agency</a>

# April 29, 2011 10:19 PM

tipsforcdevelopers said:

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.

# August 16, 2011 2:07 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)