GAC assembly version number control

Tom Knowlton
Tom Knowlton used Ask the Experts™
I want the version number for an assembly to always be

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

What am I missing?

If it 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("")]

// 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("")]
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Tom KnowltonWeb developer


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.

The AssemblyInfo looks to be correct. The screen shot that you reference is of the GAC. When you build the assembly it is not automatically install in the GAC. Try removing the old assembly from the GAC and reinstalling the one that you just rebuild. You can do that by going into the control panel/Administrative Tools/.Net Framework Configuration. Click on Assembly Cache, view list of assemblies and right click and delete on the 1.0.1634.29623. You can then go back and add the assembly.

The error message that you are getting is probably from assembly version mismatch. The ASP page is probably linked with the assembly but it can only see the 1.0.1634.29623 in the GAC.
Janice is right. What may also be the problem is if there is an old version of the DLL in some BIN or OBJ directories. Close VS and try deleting all the BIN and OBJ directories of the DLL and the projects which are supposed to use the DLL. In VS, do a rebuild all afterwards. Also, make sure to set the "Local Copy" property of the reference to false if you want the version from the GAC to be used. But keep in mind that the GAC is not automatically updated, and that forcing the version number like that will make you end up with different DLLs which all seem the same to the system!
PMI ACP® Project Management

Prepare for the PMI Agile Certified Practitioner (PMI-ACP)® exam, which formally recognizes your knowledge of agile principles and your skill with agile techniques.

Tom KnowltonWeb developer


I think you both provided necessary pieces of the puzzle.

You were both 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 ;-)
Tom KnowltonWeb developer


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).
Tom KnowltonWeb developer



>>>>>>>(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).<<<<<<<<<<



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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial