How to dynamically load strong name assemblies

10 Mar 2005 4:40 PM

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

10 Mar 2005 5:36 PM

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.

--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

<lanky***@yahoo.com> wrote in message

Show quoteHide quote

news:1110472854.106551.244770@l41g2000cwc.googlegroups.com...
> 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
>

10 Mar 2005 10:17 PM

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

11 Mar 2005 12:44 AM

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

lanky***@yahoo.com wrote:
Show quoteHide quote

> 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
>