Locate GAC assembly if only Build or Revision number is changed

Question

I have question over how CLR handles assembly binding and loading from GAC if build and revision numbers are changed. Assembly has four parts [Major].[Minor].[Build].[Revision]. I know that if Major and Minor is changed, you need publisher policy to locate newer version of assembly from GAC. What if just Build or revision number is changed? In my below scenario, it doesn't work with build and revision updates.

In my application, I have an assembly info as [1.0.*] so TFS builds assembly with [1.0.5414.23455] numbers in incremental manner on every build. Every day TFS builds project and generate assembly with increment Build and Revision numbers. This is expected behavior as I indicated wild card [1.0.*] in AssemblyInfo file.

Now, I have client application which is built against my application version [1.0.5414.23455]. I am deploying my application to GAC using installer. Now, Client application works fine if GAC has application assembly version [1.0.5414.23455] but if I install newer version (technically nothing changed, just new nightly build) [1.0.5414.23456] in GAC, client application won't load this new version.

I was referring to some Microsoft blogs/docs and found that as long as Major and Minor numbers are same, client application should be able to load assembly from GAC. Build and revision numbers are not mandatory check while locating assembly from GAC.

Is it correct that Build and revision number changes do not have any impact in locating assembly from GAC?

Thanks in advance.

With strong name key file and standard way of assigning through Visual Studio properties. — Dotnet_Dev
All 4 numbers are relevant and checked. So just changing the build or revision is enough to force you to use a bindingRedirect or publisher policy. You never want to store an assembly with an auto-generated version number in the GAC, way too much pollution and headache. Only use the GAC on the user's machine. Look at "semantic versioning". — Hans Passant

Dalorzo Dalorzo · Accepted Answer · 2014-12-02T16:57:46

To avoid some compiling complexities with newer components versions deployed on the GAC you can use bindingRedirect in your web.config or app.config like:

 <runtime>
    <generatePublisherEvidence enabled="false" />
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="MyComponent.Web.UI" publicKeyToken="121fae78165ba3d4" />
        <bindingRedirect oldVersion="1.0.5414.23455" newVersion="1.0.5414.23455" />
      </dependentAssembly> ...

Note that the attribute oldVersion represents also represents a range of versions to replace oldVersion="1.0.0.35-1.0.1016.35" and the attribute newVersion means the replacing version newVersion="2.0.1205.35"

As per your question, Why we need the bindingRedirect?

The dependencies of an assembly are part of the metadata of the assembly and you may be able to see this using something called gacutil( it is a tool part of the .NET SDK Tools) or as I did below using .NET Reflector. Since references and its versions are part of the assemblies, compilation or changing the app.config reference is required to reference a new version.

enter image description here

Locate GAC assembly if only Build or Revision number is changed

1 Answers