none
How to bind to different versions of an assembly? RRS feed

  • Question

  • Hello everyone,

    I have an app that binds to an assembly in GAC. The assembly can have two versions (say 9 and 10 for simplicity) (there will be more in future) and the app can work with either of the two versions, it doesn't care. However, because the app is bound to version 9 and deployed on a machine with version 10 on it, the app fails to load the assembly with version 9 and breaks.

    The app may be deployed on any workstation, (version 9 or 10) we don't know. Assembly redirect tag in application configuration wouldn't work because we don't know what version is in GAC. Does anyone know how to address this situation?

    TIA

    • Edited by Okash Khawaja Tuesday, October 5, 2010 10:33 AM spelling mistakes correction
    Tuesday, October 5, 2010 10:32 AM

Answers

  • You can:

    • check and load the assembly at runtime,
    • remove the strong name from that shared assembly and transform it in a private assembly. So, you will have to deploy it in your application folder.

    Good luck

    • Marked as answer by Okash Khawaja Tuesday, October 5, 2010 4:00 PM
    • Unmarked as answer by Okash Khawaja Tuesday, October 5, 2010 4:00 PM
    • Marked as answer by Okash Khawaja Tuesday, October 5, 2010 4:00 PM
    Tuesday, October 5, 2010 3:40 PM

All replies

  • You can:

    • check and load the assembly at runtime,
    • remove the strong name from that shared assembly and transform it in a private assembly. So, you will have to deploy it in your application folder.

    Good luck

    • Marked as answer by Okash Khawaja Tuesday, October 5, 2010 4:00 PM
    • Unmarked as answer by Okash Khawaja Tuesday, October 5, 2010 4:00 PM
    • Marked as answer by Okash Khawaja Tuesday, October 5, 2010 4:00 PM
    Tuesday, October 5, 2010 3:40 PM
  • Hooking into AppDomain.CurrentDomain.AssemblyResolve event is what I am doing now. The assembly should be in GAC and we're not sure about re-distribution requirements of the DLL. Plus shipping it will bloat the installer. I was looking for a simple lazy solution like putting some XML in application configuration file? Thanks for your help anyway.
    Tuesday, October 5, 2010 4:00 PM
  • Thank you for your answer Mr. Okash.

    Please, tell me if I'm wrong:

    • You have an application that can use a different shared assembly version depending on what version is installed on your client machine;
    • So, the Xml configuration setting it's worthless, because in fact, you have to look in GAC to find what version it's installed on such machine;
    • After finding it, you will have to load it whitout worries about wich version it is;

     

    I Just need to know exactly where you want to go, in order to help you ( and I'm a little confuse). Please, guide me through this questions. It will help me a lot!

     

    Good luck!

     

     

     

    Tuesday, October 5, 2010 4:20 PM
  • You are right, my app doesn't care which version of the assembly gets loaded. 
    Tuesday, October 5, 2010 4:32 PM
  • Hi Christiano Coutinho

    When you build a .NET Framework application against a strong-named assembly, the application uses that version of the assembly at run time by default, even if a new version is available. However, you can configure the application to run against a newer version of the assembly.

    The following example shows how to redirect one assembly version to another.

    <configuration>
      <runtime>
       <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
          <assemblyIdentity name="myAssembly"
                   publicKeyToken="32ab4ba45e0a69a1"
                   culture="neutral" />
          <bindingRedirect oldVersion="1.0.0.0"
                   newVersion="2.0.0.0"/>
         </dependentAssembly>
       </assemblyBinding>
      </runtime>
    </configuration>
    
    Quoted from MSDN
    Tuesday, October 5, 2010 8:36 PM
  • Thak you Mr. Islam. I already saw a few examples about assembly redirection ( I never used it in fact ). But it doesn't seem to be a solution for our friend Okaj :

    he wrote:
    >> Assembly redirect tag in application configuration wouldn't work because we don't know what version is in GAC.

    But anyway: any effort in order to help somebody it's valid.

    Thank you!

    Tuesday, October 5, 2010 9:09 PM
  • Thank you Mr. Okash!

    I was looking for some references in order to help you and found something interesting that MAY help you:

    http://msmvps.com/blogs/p3net/pages/redirecting-dependent-assembly-versions-in-net.aspx

    The bindingRedirect element tells the loader that instead of using v10.0 of the assembly we should instead use v11.0.  This allows us to use newer versions of an assembly even though we compiled with an older version.  Of course if the versions are not compatible then a runtime error will occur.

    Wildcards are not allowed in the oldVersion attribute but you can specify a range of versions like so: 10.0.0.0-10.99.99.99.  This allows you to redirect all versions of an assembly to a newer version

    Have you tried this?

     

    Thank you!

     

     

    Tuesday, October 5, 2010 9:18 PM
  • Assembly.LoadWithPartialName will suit my particular situation but it is deprecated as it can result in completely different version of assembly getting loaded (http://blogs.msdn.com/b/suzcook/archive/2003/05/30/57159.aspx?wa=wsignin1.0). Therefore, I will look for particular versions by hooking into AppDomain.CurrentDomain.AssemblyResolve failing which the end user will be advised to use assembly redirect tag in application configuration file. 

     

    @Christiano bindingRedirect tag on it own is not useful for me because GAC might have the version that I built the app with. For example if I built with version 10 and then if I put a binding redirect from 10 to 9, that will result in 9 being loaded every time even if the version in GAC is 10 (which is valid too). Plus using ranges may result in Dll H3ll, the very reason for which Assembly.LoadWithPartialName method is marked as deprecated.

     

    Thanks guys for your help!

    • Edited by Okash Khawaja Wednesday, October 6, 2010 3:33 PM changed from Dll ____ to Dll H3ll because ____ was censored
    Wednesday, October 6, 2010 3:29 PM