How to resolve .NET Core package version conflicts

后端 未结 2 1221
自闭症患者
自闭症患者 2021-02-05 07:50

I am migrating from a .NET MVC 5 Web Application to a .NET Core 2.2 Web API project along with five .NET Standard 2.0 projects all housed under one solution.

I am now r

相关标签:
2条回答
  • 2021-02-05 08:20

    Binding redirect (bindingRedirect ) for every assembly you can do it manually in config or there is an option in Project file properties. Check it then upgrade.

    0 讨论(0)
  • 2021-02-05 08:36

    The issue is here strong naming and mixed assembly versions for at least "System.Collections.Concurrent", but probably for all the 28 warnings.

    I tried going into NuGet at the solution level to install the missing assembly, but 4.0.14 isn't even available in the selection list.

    The versions you are seeing are the NuGet versions, and those aren't the same to the assembly versions. e.g. NuGet version 4.3.0-preview1-24530-04 has assembly version 4.0.13.0 for .NET standard 1.3:

    Please note that in the same package, the assembly version for netcore50 is 4.0.10.0!

    Is this a Microsoft bug?

    No it's a feature. When an assembly is strong named., then the full version should match. If not, this will give a warning. When not using the GAC, then only one version of the assembly could be published - so which one if multiple versions are used? Note- all Microsoft's assemblies are strong named.

    The problem here:

    • You are including an (strong named) assembly that's built to System.Collections.Concurrent assembly version 4.0.14.0
    • You are (indirectly) using in your application assembly version 4.0.11.0 for the System.Collections.Concurrent assembly.

    So two version for one assembly!

    Solutions

    There are multiple solutions possible:

    1. Use everywhere the same assembly version for System.Collections.Concurrent (you need to find out which NuGet package is assembly version 4.0.14.0). This is most of the time not feasible.
    2. Install the version 4.0.11.0 and 4.0.14.0 into the GAC - this ins't a really popular option either these days -> Not possible for .NET Core as there is no GAC for .NET Core. See Is there any GAC equivalent for .NET Core?
    3. Use a <bindingRedirect> in your .config. See Redirecting Assembly Versions | Microsoft Docs

      e.g. for "System.Collections.Concurrent":

      <dependentAssembly>
          <assemblyIdentity name="System.Collections.Concurrent" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
          <bindingRedirect oldVersion="4.0.0.0-4.0.14.0" newVersion="4.0.11.0" />
      </dependentAssembly>
      

    Final notes

    There are 28 version issues, but there is a big change that multiple issues are solved with a single bindingRedirect. So the best way is to start with one (preferable the most top-level one), and rebuild and repeat until all are resolved.

    Please also note that downgrading an assembly is a bit tricky, e.g the assembly built on 4.0.13.0 could use a feature that is introduced/changed in 4.0.11.0+. So you could also update your version and use that version in "newVersion" attribute

    0 讨论(0)
提交回复
热议问题