2

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.

Dotnet_Dev
  • 21
  • 2
  • How are you strong-naming your assembly? – user1620220 Dec 02 '14 at 16:56
  • With strong name key file and standard way of assigning through Visual Studio properties. – Dotnet_Dev Dec 02 '14 at 17:03
  • 1
    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 Dec 02 '14 at 17:17

1 Answers1

0

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

Dalorzo
  • 19,834
  • 7
  • 55
  • 102
  • Yup, I know about this and I mentioned abt publisher policy in my question. I am specifically wanted to know that whether just Build and revision number changes causing failure in GAC assembly loading. – Dotnet_Dev Dec 02 '14 at 17:02
  • Most likely you are not compiling all the components against the new version and that may create discrepancies – Dalorzo Dec 02 '14 at 17:03
  • Why compilation is required if technically nothing changed. Assembly is just got new build and revision numbers due to TFS nightly build. That's all, not a single line code change. Why one should ask client to recompile their app for no or minor change. – Dotnet_Dev Dec 02 '14 at 17:05
  • @Dotnet_Dev I updated my answer with additional details. – Dalorzo Dec 02 '14 at 17:17
  • Even I have mentioned [1.0.\*] in AssemblyInfo.cs file, Does it refer to Build and revision numbers while locating from GAC...It means that It Build and revision numbers are auto generated and not SPECIFIC... – Dotnet_Dev Dec 02 '14 at 17:51
  • @Dotnet_Dev I think the answer above stands as it is the how .net works – Dalorzo Dec 02 '14 at 20:10