3

Specifically this question is about dependency conflicts with the runtimes.

I have an ASP.NET Core 6 application. This application starts at Project A (the website project). Project A uses Project B - a class library which I've written to do some business context specific work. Nothing special.

However, I've noticed that I can't publish the application as self-contained. Project B has a nuget package reference to System.Text.Encoding.CodePages v7.0.0.0. (\<PackageReference Include="System.Text.Encoding.CodePages" Version="7.0.0" /\>)

This is fine when I publish the application in the usual runtime-dependent manner. But when I publish it as a self-contained application the Project B deps.json file includes a target for runtimepack.Microsoft.NETCore.App.Runtime.win-x64/6.0.16.

runtimepack.Microsoft.NETCore.App.Runtime.win-x64/6.0.16 in turn references System.Text.Encoding.CodePages v6.0.0.0.

So what I end up with is a publish output directory that contains a v6.0.0.0 DLL for System.Text.Encoding.CodePages.

I think I'm right in saying that the issue is when building self-contained, dotnet has to include the runtime in the publish output, which is why it's adding runtimepack.Microsoft.NETCore.App.Runtime.win-x64/6.0.16. And then because it includes runtimepack.Microsoft.NETCore.App.Runtime.win-x64/6.0.16 it has to include CodePages v6.0.0.0.

(Though if anyone wants to fact-check those two assumptions for me I'd also appreciate that)

So my question is: In this situation is there anyway to force dotnet to use v7.0.0.0 in the publish output?

Extra details:

  • I'm publishing through the command:

      dotnet publish -c Release -o ./build_output --self-contained true -r win10-x64

  • The functional impact between the two DLL versions is so minimal that if I manually copy the v7 DLL from a runtime-dependent build in to the self-contained build directory it will make the whole app work.

For now, I've just installed the runtime on our servers and used the runtime-dependent build process. But I'd still like to know the answer to this question.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
NickStafford
  • 31
  • 1
  • You control the source code to Project B? then downgrade the dependency in your .csproj? – Jeremy Lakeman Apr 26 '23 at 01:12
  • @JeremyLakeman That's a fair option and one that I did consider. It would have worked in this case but, the question still stands on it's own merit for situations where that's not possible or desired. – NickStafford Apr 26 '23 at 16:38
  • When a dependency declared on the minimum supported version, any referencing project can upgrade the dependency to a newer version. So, does the conflicted version has any upgraded version or vice-versa? You could [`have a look on this thread which might be helpful`](https://stackoverflow.com/questions/5916855/using-multiple-versions-of-the-same-dll) – Md Farid Uddin Kiron Apr 28 '23 at 05:37
  • @MdFaridUddinKiron your answer is incorrect. As per the documentation: https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution The lowest dependency version shared between the different references is used. Additionally the post you referenced is 11 years old and cannot apply to .NET Core. The accepted answer on the thread you mentioned references binding redirects which are only applicable to .NET Framework. – NickStafford Apr 30 '23 at 06:06
  • Thanks for your response. Yes that's a older post, I referred if that help you to resolve your issue. – Md Farid Uddin Kiron May 01 '23 at 01:07

0 Answers0