none
Redirecting assembly versions at the app level RRS feed

  • Question

  • I need some guide line for assembly versions redirection.

    i read this link https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions

    they suggest to use

    <dependentAssembly>  
      <assemblyIdentity name="someAssembly"  
        publicKeyToken="32ab4ba45e0a69a1"  
        culture="en-us" />  
      <bindingRedirect oldVersion="7.0.0.0" newVersion="8.0.0.0" />  
    </dependentAssembly>  

    1) whenever i add reference of any assembly in project then i never saw above xml tags related info in app.config or web.config file. so my question is when the above bindingRedirect is added in app.config or web.config file ?

    2) when we add any assembly to my project from gac then the above bindingRedirect is added in app.config or web.config file ?

    3) or we manually need to add the above xml in app.config or web.config file ?

    4) after adding the binding redirect <bindingRedirect oldVersion="7.0.0.0" newVersion="8.0.0.0" /> 

    my project automatically start pointing to version 8.0.0.0 ?

    5) How do i know at design time that my project is pointing to version 8.0.0.0 ?

    please answer point wise. thanks

    Thursday, June 21, 2018 11:27 AM

Answers

  • Binding redirects are not something you normally need. The purpose of a binding redirect is to allow you to adjust an existing project to use a newer version of a strongly named assembly without having to recompile the app. It is generally only done for hotfixes. It is occasionally done when it doesn't depend on an assembly directly but relies on something that does. NuGet will generally handle this for you.

    Think of it this way. At the point of compilation the compiler will look at all the strongly named assemblies you are referencing (and using). For each one it puts a metadata element into the assembly pointing to that specific version. At runtime the CLR reads the metadata and expects to find that exact version. If it doesn't then it errors out. MSDN documents this process. A binding redirect is a way to tell the CLR to allow for (generally) newer versions of the assembly. If the referenced assembly version falls in the range given then the CLR can use the (newer) version that is specified. It is strictly and override for the CLR.

    1) Binding redirects are exceptions, not the norm. You shouldn't generally need them.

    2) It may be added or it may not. You don't actually need it if your app has added a reference to the strongly named assembly. It is only needed if you're upgrading from an older version and you aren't recompiling your code.

    3) It is rare you will need it so don't add anything. Ensure you are using the latest version of the NuGet packages and everything will just work. If you have dependencies of dependencies then you may get compiler warnings about mismatched versioning. In this case though the later versions of VS will allow you to double click the warning and they will auto-add the redirect for you. You don't have to do anything manually.

    4) No. Your project will continue to point to whatever assembly version the reference you added points to. To change what version your project uses you have to update the reference either via NuGet (preferred) or by removing and adding the (updated) reference back. The binding redirect only impacts what version(s) of the assembly the CLR will consider at runtime. It has absolutely no impact on your original reference - hence why it is a warning in the compiler.

    5) You don't. Again binding redirects are a runtime thing. At compile time the assembly you're referencing is the version that you added a reference to. Change the reference to change the version you're using.



    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Sudip_inn Sunday, June 24, 2018 4:34 PM
    Thursday, June 21, 2018 1:48 PM
    Moderator

All replies

  • Binding redirects are not something you normally need. The purpose of a binding redirect is to allow you to adjust an existing project to use a newer version of a strongly named assembly without having to recompile the app. It is generally only done for hotfixes. It is occasionally done when it doesn't depend on an assembly directly but relies on something that does. NuGet will generally handle this for you.

    Think of it this way. At the point of compilation the compiler will look at all the strongly named assemblies you are referencing (and using). For each one it puts a metadata element into the assembly pointing to that specific version. At runtime the CLR reads the metadata and expects to find that exact version. If it doesn't then it errors out. MSDN documents this process. A binding redirect is a way to tell the CLR to allow for (generally) newer versions of the assembly. If the referenced assembly version falls in the range given then the CLR can use the (newer) version that is specified. It is strictly and override for the CLR.

    1) Binding redirects are exceptions, not the norm. You shouldn't generally need them.

    2) It may be added or it may not. You don't actually need it if your app has added a reference to the strongly named assembly. It is only needed if you're upgrading from an older version and you aren't recompiling your code.

    3) It is rare you will need it so don't add anything. Ensure you are using the latest version of the NuGet packages and everything will just work. If you have dependencies of dependencies then you may get compiler warnings about mismatched versioning. In this case though the later versions of VS will allow you to double click the warning and they will auto-add the redirect for you. You don't have to do anything manually.

    4) No. Your project will continue to point to whatever assembly version the reference you added points to. To change what version your project uses you have to update the reference either via NuGet (preferred) or by removing and adding the (updated) reference back. The binding redirect only impacts what version(s) of the assembly the CLR will consider at runtime. It has absolutely no impact on your original reference - hence why it is a warning in the compiler.

    5) You don't. Again binding redirects are a runtime thing. At compile time the assembly you're referencing is the version that you added a reference to. Change the reference to change the version you're using.



    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Sudip_inn Sunday, June 24, 2018 4:34 PM
    Thursday, June 21, 2018 1:48 PM
    Moderator
  • you said

    3) It is rare you will need it so don't add anything. Ensure you are using the latest version of the NuGet packages and everything will just work. If you have dependencies of dependencies then you may get compiler warnings about mismatched versioning. In this case though the later versions of VS will allow you to double click the warning and they will auto-add the redirect for you. You don't have to do anything manually.

    suppose i installed a setup for a 3rd party library which place its assembly in GAC. the version of the library say 1.0

    then i point to that library from VS IDE. after few months i again install the upper version of same library in same pc. now tell how my VS IDE or project can point to upper version with dropping existing reference and adding new reference of upper version of library automatically ?

    tell me what to do that my project should point to upper version without recompiling code. give full instruction step-by-step.

    thanks

    Sunday, June 24, 2018 4:42 PM
  • In the rare case where you need to use a new assembly without recompiling your code then the binding redirect entry in the config is the correct solution. The MSDN docs provide the steps but they are basically the same as you original posted. Are you having an issue getting the redirect to work in your case?

    Note that redirects are a stopgap. The correct solution is to recompile your code to use the new assembly at your earliest convenience. Going forward .NET Core won't use the GAC so storing assemblies in the GAC is going to go to the wayside as code retargets to .NET Standard. 


    Michael Taylor http://www.michaeltaylorp3.net

    Sunday, June 24, 2018 8:44 PM
    Moderator
  • Thanks for the reply. this is not clear what you said Going forward .NET Core won't use the GAC so storing assemblies in the GAC is going to go to the wayside as code retargets to .NET Standard

    in .net core there is no concept about GAC ? if there is no GAC then where shared assembly lies or stored ?

    please guide me. thanks

    Wednesday, June 27, 2018 5:59 PM
  • Prior to v2 there is no shared assemblies other than the .NET core runtime (framework dependent deployments). This is/was by design. It meant that users installing an app don't suddenly break other apps that might have been using the same framework version.

    In .NET Core v2 there is the runtime package store where pre-packaged binaries can go. It is not quite the same as a GAC but serves a similar purpose. The idea is to reduce the # of binaries your app has to ship. It is a happy medium between no shared assemblies and self contained deployments


    Michael Taylor http://www.michaeltaylorp3.net

    Wednesday, June 27, 2018 6:17 PM
    Moderator