Link to home
Start Free TrialLog in
Avatar of Tom Knowlton
Tom KnowltonFlag for United States of America

asked on

GAC assembly version number control

I want the version number for an assembly to always be 1.0.0.0

http://www.robotzgame.com/junk/GACver.bmp

FormattingLib    version number is incrementing.....even though in the AssemblyInfo file....I have expressly set it to "1.0.0.0"

What am I missing?

If it helps....here is the AssemblyInfo file for FormattingLib DLL:


=========================================================


using System.Reflection;
using System.Runtime.CompilerServices;

//
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
//
[assembly: AssemblyTitle("")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("")]
[assembly: AssemblyCopyright("")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]            

//
// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '*' as shown below:

[assembly: AssemblyVersion("1.0.0.0")]

//
// In order to sign your assembly you must specify a key to use. Refer to the
// Microsoft .NET Framework documentation for more information on assembly signing.
//
// Use the attributes below to control which key is used for signing.
//
// Notes:
//   (*) If no key is specified, the assembly is not signed.
//   (*) KeyName refers to a key that has been installed in the Crypto Service
//       Provider (CSP) on your machine. KeyFile refers to a file which contains
//       a key.
//   (*) If the KeyFile and the KeyName values are both specified, the
//       following processing occurs:
//       (1) If the KeyName can be found in the CSP, that key is used.
//       (2) If the KeyName does not exist and the KeyFile does exist, the key
//           in the KeyFile is installed into the CSP and used.
//   (*) In order to create a KeyFile, you can use the sn.exe (Strong Name) utility.
//       When specifying the KeyFile, the location of the KeyFile should be
//       relative to the project output directory which is
//       %Project Directory%\obj\<configuration>. For example, if your KeyFile is
//       located in the project directory, you would specify the AssemblyKeyFile
//       attribute as [assembly: AssemblyKeyFile("..\\..\\mykey.snk")]
//   (*) Delay Signing is an advanced option - see the Microsoft .NET Framework
//       documentation for more information on this.
//
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("..\\..\\key.snk")]
[assembly: AssemblyKeyName("")]
Avatar of Tom Knowlton
Tom Knowlton
Flag of United States of America image

ASKER

I am also getting this:


# Error Type:
GenDocRequestOnly (0x80131040)
The located assembly's manifest definition with name 'FormattingLib' does not match the assembly reference.
/test_gendocreqonly.asp, line 2

# Browser Type:


From the ASP page that is calling a DLL that USES FormattingLib but does not call it directly.

Tom
ASKER CERTIFIED SOLUTION
Avatar of JaniceLaw
JaniceLaw

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I think you both provided necessary pieces of the puzzle.

You were both correct....it ended-up being necessary to remove the entries both from the GAC and the hard drive...and then I was finally able to resolve these problems!

Nicely done, Expert JaniceLaw and Expert AvonWyss!!
Thank you for the feedback, and happy coding ;-)
What I don't get is if in the beginning I was running regasm and gacutil on the file in question....why didn't the GAC and the assembly reference (C:\WINNT\Assemblies) update accordingly?

In other words, running THIS:

copy <dll> to <c:\winnt\system32>
regasm <dll path> /unregsister
regasm <dll path>
gacutil -i <dll path>


does NOT update the GAC if the assembly is already there?

This is exactly what I was doing before following your advice.
Well, if I remember right, this DLL had a fixed version number. In this case, GACUTIL was asuming that it was the very same DLL - and therefore didn't update it. With changing version numbers, this does not happen. In fact, modifying code and reusing the version number is a dangerous thing, and mainly the reason for the "dll hell" we had before .NET - because there was no versioning support. Now if you fix the version number, you are in fact throwing away these advantages, and you sort of get what you deserve for doing that ;-)

(Note that there can be multiple versions of the very same DLL in the GAC, so that apps can pick the one which they know will work for them).
AvonWyss:

>>>>>>>(Note that there can be multiple versions of the very same DLL in the GAC, so that apps can pick the one which they know will work for them).<<<<<<<<<<

Really????????

Hmmmm......

I'll have to think about this some.  To be honest with you, I was worried by all of the different versions of the same assembly in the GAC.  I didn't feel like I had any control over what was happening.



The idea of versioning control is that each app pickt the version of the DLL it was installed with. This prevents any unwanted side-effects from updating a DLL and also allows to have interface changes in the DLL, since old apps will not be affected by it. As a software pubisher, you can, however, also publish a policy file which substitutes versions. This means that you can have only V2.0.0.0 of your DLL installed plus a policy file which tells .NET to use this V2 DLL for V1.*.*.* applications. This will force the .NET runtime to use the new DLL instead of the old, despite the unmatching version number. Note that this does ONLY work if the new DLL does implement the complete interface of the old version and also behaves compatible (except for maybe some bug fixes). Added code is, however, not a problem.