how much of this is still true (assembly versioning & the gac)

  • Thread starter Thread starter Coaster
  • Start date Start date
C

Coaster

orig ref here
http://groups.google.com/group/micr...+assembly+new+version&rnum=7#c0db5b7e3da283b9


I have pasted the part I'm interested in below. My company doesn't use
versioning or the gac and I'd like to. We're on vs.net 2005 & .net 2., is
this still true or has it changed since then?

thanks
That article is not entirely accurate. As long as you don't make a change
that causes the assembly hash value to change, you can update a new version
of the assembly in the GAC and the ASP.NET application will automatically
use the new version without changing anything. (It should be noted that
you do still have to reload the app domain.)


What changes the hash value? If you change the assembly name, the major or
minor version, the public key token, or the culture, the hash value will
change. As long as you don't modify any one of these, you would use the
following procedure to update the assembly in the GAC.


1. Run sn to create a new verification entry for the new version. Do that
as
follows:


sn -Vr <assembly>


2. Run Gacutil to reinstall the assembly as follows:


gacutil /nologo /if <assembly>


Once you do that, simply open the web.config, add a new blank line, and
save the web.config. That will force a reload of the app domain and your
application will use the new assembly.


If you have changed the hash value by changing one of the above, the
easiest way to force your application to use the new version in cases where
you can't redirect the assembly binding in a configuration file is to use a
publisher policy assembly. Most people will say that you should use a
publisher policy file, but that's not entirely accurate. The publisher
policy file is used to create the publisher policy assembly, and it's
actually the publisher policy assembly that redirects the binding.


Here is an example of doing this. In this example, my assembly is called
jcGAC.dll and I am changing the version number from 1.0.0.0 to 2.0.0.0.


1. Change code in version 1.0.0.0 of the assembly.


2. Change version number in assemblyinfo.cs to reflect new version.


3. Rebuild assembly.


4. Create publisher policy file in any text editor. You will need to
replace "<public_key>" with the public key for your version 1.0 assembly.


<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="jcGAC"
publicKeyToken="<public_key>"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>


5. Use al to create the publisher policy assembly. The publisher policy
assembly MUST have the following file format:
policy.major_ver.minor_ver.assembly.dll


The major and minor version shown here would be the major and minor
versions for your original version, not the updated new version. Below is
an example of the command entered to create the publisher policy assembly
for my assembly jcGAC.dll using the keyfile jcgac.snk. Note that the
publisher policy file in created in step 4 was saved as pub.config.


al /link:pub.config /out:policy.1.0.jcGAC.dll /keyfile:jcgac.snk


6. Install publisher policy assembly into the GAC.


gacutil /i policy.2.0.jcGAC.dll


7. Install version 2.0.0.0 of your assembly into the GAC.


gacutil /i jcGAC.dll


8. Restart the app domains by either saving a change to the machine.config
or by resetting IIS.


9. Run the ASP.NET app.


After taking these steps, any ASP.NET application that originally
referenced version 1.0.0.0 will now bind to version 2.0.0.0.


Assembly binding is a fairly complex subject, but I hope that this helps
explain a bit.


Jim Cheshire, MCSE, MCSD [MSFT]
 
A couple new questions, (assuming this is uptodate which I think it is)

in one week I have this
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
Click to expand...

then next week I have a new major version, do I do this
<bindingRedirect oldVersion="1.0.0.0"
newVersion="3.0.0.0"/>
Click to expand...

or this
<bindingRedirect oldVersion="2.0.0.0"
newVersion="3.0.0.0"/>
Click to expand...


and second ,

if we're currently not using versioning at all meaning there is no
assemblyinfo file set up with any version (which I think means we're always
at 1.0.0.0.) , how much work would it be to implement this. Could I just
version the new version of the component (aka add the assemblyinfo file and
set it to 1.1.0.0 or 1.0.0.1) and add the versioning policy assembly and not
have to recompile the 20 something apps that are using it . Assuming the
function params don't change?


Thanks




Coaster said:
orig ref here
http://groups.google.com/group/micr...+assembly+new+version&rnum=7#c0db5b7e3da283b9


I have pasted the part I'm interested in below. My company doesn't use
versioning or the gac and I'd like to. We're on vs.net 2005 & .net 2., is
this still true or has it changed since then?

thanks
That article is not entirely accurate. As long as you don't make a change
that causes the assembly hash value to change, you can update a new
version
of the assembly in the GAC and the ASP.NET application will automatically
use the new version without changing anything. (It should be noted that
you do still have to reload the app domain.)


What changes the hash value? If you change the assembly name, the major
or
minor version, the public key token, or the culture, the hash value will
change. As long as you don't modify any one of these, you would use the
following procedure to update the assembly in the GAC.


1. Run sn to create a new verification entry for the new version. Do
that
as
follows:


sn -Vr <assembly>


2. Run Gacutil to reinstall the assembly as follows:


gacutil /nologo /if <assembly>


Once you do that, simply open the web.config, add a new blank line, and
save the web.config. That will force a reload of the app domain and your
application will use the new assembly.


If you have changed the hash value by changing one of the above, the
easiest way to force your application to use the new version in cases
where
you can't redirect the assembly binding in a configuration file is to use
a
publisher policy assembly. Most people will say that you should use a
publisher policy file, but that's not entirely accurate. The publisher
policy file is used to create the publisher policy assembly, and it's
actually the publisher policy assembly that redirects the binding.


Here is an example of doing this. In this example, my assembly is called
jcGAC.dll and I am changing the version number from 1.0.0.0 to 2.0.0.0.


1. Change code in version 1.0.0.0 of the assembly.


2. Change version number in assemblyinfo.cs to reflect new version.


3. Rebuild assembly.


4. Create publisher policy file in any text editor. You will need to
replace "<public_key>" with the public key for your version 1.0 assembly.


<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="jcGAC"
publicKeyToken="<public_key>"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>


5. Use al to create the publisher policy assembly. The publisher policy
assembly MUST have the following file format:
policy.major_ver.minor_ver.assembly.dll


The major and minor version shown here would be the major and minor
versions for your original version, not the updated new version. Below is
an example of the command entered to create the publisher policy assembly
for my assembly jcGAC.dll using the keyfile jcgac.snk. Note that the
publisher policy file in created in step 4 was saved as pub.config.


al /link:pub.config /out:policy.1.0.jcGAC.dll /keyfile:jcgac.snk


6. Install publisher policy assembly into the GAC.


gacutil /i policy.2.0.jcGAC.dll


7. Install version 2.0.0.0 of your assembly into the GAC.


gacutil /i jcGAC.dll


8. Restart the app domains by either saving a change to the
machine.config
or by resetting IIS.


9. Run the ASP.NET app.


After taking these steps, any ASP.NET application that originally
referenced version 1.0.0.0 will now bind to version 2.0.0.0.


Assembly binding is a fairly complex subject, but I hope that this helps
explain a bit.


Jim Cheshire, MCSE, MCSD [MSFT]
Click to expand...
 
Back
Top