assembly versioning
-
My applications use a large number of components (DLLs and EXEs) which previously (using VC6.0) we built using a big build script, and then at the end we ran a program over all the modules which stamped them all with exactly the same version. This made it very easy to tell if a customer has a consistent version of all the components. Recently I've just created a .NET component that will be released with the rest of the applications. My question is: Is there any way to set the assembly version of an assembly that has already been generated? With the normal Win32 modules I can load then and then modify the resources using the appropriate APIs - but will this work for a .NET component - particularly since the version is part of the strong name of the component? Dave http://www.cloudsofheaven.org
-
My applications use a large number of components (DLLs and EXEs) which previously (using VC6.0) we built using a big build script, and then at the end we ran a program over all the modules which stamped them all with exactly the same version. This made it very easy to tell if a customer has a consistent version of all the components. Recently I've just created a .NET component that will be released with the rest of the applications. My question is: Is there any way to set the assembly version of an assembly that has already been generated? With the normal Win32 modules I can load then and then modify the resources using the appropriate APIs - but will this work for a .NET component - particularly since the version is part of the strong name of the component? Dave http://www.cloudsofheaven.org
You can use the Win32 resource editing trick for the version of the executable, but not the assembly. Doing this will also invalidate signature if you use signed assemblies (and you should be, especially since it makes versioning easier via config files and policy assemblies, which must be in the GAC and assemblies in the GAC must be signed). Even if you did change the version and resign the assembly, it still wouldn't be an easy task. You would have to emit an assembly based on a template (the existing assembly). Frankly, IMO, just implement a policy whereby your developers put the appropriate assembly version into the
[assembly: AssembyVersionAttribute]when compiling for the last time. Or, if you have a build master, he or she could either do it (or use a macro to change the AssemblyInfo.cs file (or wherever you put it) to make it quick) and then compile under a release build. Just remember that the version number in the VersionInfo block of the executable's .rsrc section has little to no bearing on the assembly itself. TheAssemblyVersionattribute is what matters, and that's in the MANIFEST for the assembly. One example: Infragistics commonly updates their assemblies while leaving theAssemblyVersionAttributewith the same value, but changes the executable image's VersionInfo block so that the FileVersion is different. While this makes updating your applications without recompiling easier, it totally screws-over touchless deployment over the Internet because Fusion (the assembly binder) caches assemblies based on their strong name in the temporary assembly cache. Since the assembly version didn't change, the new code isn't always downloaded! (The cases where it is depends on Internet Explorer's cache settings.)-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----