How to dynamically load strong name assemblies

[lanky_tx]

Hi All,

We have an automated build and test environment using NAnt and Nunit.
Some of our assemblies are being strong named by modifying the
AssemblyInfo.cs and having csc compile it. Some of these strong named
assemblies are being dynamically loaded into the runtime. We store the
metadata information about the strong named assemblies in a config
file.

Metadata in the config file looks like this:

MyAssembly.Name.Here,Version=1.0.x.x, Culture=neutral,
PublicKeyToken=xxxxxxx

Here is the problem. When conducting a build, the Version of the
strong named assemblies increment. The config file has not been
updated to reflect this change (Because in theory we shouldn't have to
change the config file all the time). Therefore, when the Nunit tests
run and try to load the assemblies to test in runtime it'll fail
becuase the version info is incorrect.

I thought about this and thought of delay-signing the assemblies after
the Nunit tests complete, but then when it is deployed the problem
still persists.

Does anyone have any ideas on loading strong names assemblies
dynamically storing the metadata in a config file in an automated build
environment?


I know this is a long read and thanks to all.

md

 

[Phil Wilson]

It's not difficult to find out those attributes and update a config file -
is that what you're asking? AssemblyName.GetAssemblyName(path) followed by
calls to Version and GetPublicKeyToken() will get you those attributes.

 

[lanky_tx]

That's very useful info. However, I am trying determine if there are
any other approaches to this issue, other than changing the config file
during the build?

Anyone?

md

 

[Joshua Flanagan]

The real solution is to stop changing your assembly version every time
you build! I say this with an exclamation point because it is a very
common mistake (aided by Microsoft's mistake of making AssemblyVersion
increment by default in AssemblyInfo.cs).

From "Applied .Microsoft .NET Framework Programming" - Jeffrey Richter,
regarding the AssemblyVersion attribute:

"When starting to develop an assembly, you should set the major, minor,
build, and revision numbers and shouldn't change them until you're ready
to begin work on the next deployable version of your assembly."

The AssemblyVersion should not change for new internal builds. Consider
it analogous to changing the assembly file name with every build:
Project1.dll, build again to produce Project2.dll, then Project3.dll.
You wouldn't want to do that, would you? That is exactly what you are
doing if you increment AssemblyVersion with every build.


Joshua Flanagan
http://flimflan.com/blog