2

I'm trying to get log4net working under a dotnetcore3.1 project. I am continuously getting spammed with errors like this:

error NU1605: Detected package downgrade: System.Diagnostics.Debug from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.  [/app/MyProject.csproj]

csproj boils down to this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <OutputType>exe</OutputType>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="log4net" Version="2.0.8" />
  </ItemGroup>
</Project>

Environment:

  • dotnetcore3.1
  • docker build image: mcr.microsoft.com/dotnet/core/sdk:3.1
  • docker runtime image: mcr.microsoft.com/dotnet/core/runtime:3.1-bionic

Unacceptable "fixes":

  • "Just add <WarningsAsErrors></WarningsAsErrors>"
  • Anything that involves opening Visual Studio

There are several posts for this problem, but they seem to either suppress the error and move on, or they use Visual Studio "magic" to solve it.

Based on this message, Reference the package directly from the project to select a different version., I've tried adding package references to my csproj, but none of "System", "System.Diagnostics", or "System.Diagnostics.Debug" work.

How do you actually fix this problem?

Please be specific. I'm still new to C# and many solutions I've found may not have worked because they simply said add <SomeXmlTag /> and I had no idea where to put it or under what parent to drop the tag.

Per Gray Cat, I tried: Adding a bindingRedirect to a .Net Standard library

Originally it didn't seem like it changed the output at all. After playing with the verbosity, I found this:

   "/app/MyProject.csproj" (Publish target) (1) ->
   (ResolveAssemblyReferences target) -> 
/usr/share/dotnet/sdk/3.1.100/Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of "System.Configuration.ConfigurationManager" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [/app/MyProject.csproj]
     /usr/share/dotnet/sdk/3.1.100/Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of "System.Security.AccessControl" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [/app/MyProject.csproj]
     /usr/share/dotnet/sdk/3.1.100/Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of "System.Security.Permissions" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [/app/MyProject.csproj]
     /usr/share/dotnet/sdk/3.1.100/Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of "System.Security.Principal.Windows" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [/app/MyProject.csproj]

Wonderfully, it's supposed to include the details, but I can't find them in the pages of output I'm looking at.

Camway
  • 1,010
  • 14
  • 23
  • Does this help : https://stackoverflow.com/questions/46111749/adding-a-bindingredirect-to-a-net-standard-library ? I think this is strange that directly addin dependency didn't help, but binding redirects should. Just pray libraries in question are backwards compatible. – GrayCat Dec 27 '19 at 20:59
  • I just tried it. Unless I've missed something, there's no change in the output. – Camway Dec 27 '19 at 21:03
  • Then maybe you should take a look on new type of reference in .NET Core 3.1 - FrameworkReference. You can read more about it here : https://andrewlock.net/exploring-the-new-project-file-program-and-the-generic-host-in-asp-net-core-3/ Maybe this will help you pull good package in. – GrayCat Dec 27 '19 at 21:21
  • I went through the article. I managed to get the new errors I posted above resolved, but none of the warnings have been resolved. I'm now in the process of writing my own logger. I've already spent 2 days trying to get log4net working, and I'm pretty sure I can write a replacement in under half that. Still willing to entertain fixes. – Camway Dec 27 '19 at 21:47
  • I know Serilog works with .NET Core pretty well if you want to try. Or use in-built Microsoft ILogger (even better!). As for new warnings, you might want to set build output verbosity in VisualStudio to Detailed to see exact causes of warnings (but post here only relevant part, this output is **massive**!) – GrayCat Dec 27 '19 at 21:53
  • 1
    Yes, log4net supports only .NET Standard 1.3, checked in NuGet. It might be that best thing you could do is just use another logger. The wider the gap between versions more obscure problems become. – GrayCat Dec 27 '19 at 21:58
  • Well that explains a lot lol. I just finished ripping out log4net, and wrote my own logger. Everything is working and I no longer have any errors/warnings in my build/runtime. Thanks for the help GrayCat – Camway Dec 27 '19 at 22:22
  • 1
    "wrote my own logger" please don't. Use .NET Core's built-in logging functionality or a logging framework that supports Core 3.1 as @GrayCat suggested. Logging is a problem that has been solved many times, don't reinvent this wheel. – Ian Kemp Dec 27 '19 at 22:41
  • Ian, if this was something more complicated, I'd agree with you. Here's the math problem in my mind. Time to read docs + verify compatibility + install + implement + test versus the hour it took me to write and implement my own. I don't need a super complicated logging system; I just need something that works and can adapt to my needs. I've already burnt days trying to get someone else's logger to work, and I know mine does work. Why would I attempt something uncertain, when in less time I've already achieved that's certain? In addition, now I have full control over it's development. – Camway Dec 28 '19 at 19:56

1 Answers1

2

we faced similar problems when trying to build some of our .NET Core 3.1 services. The downgrade message was the same, although for different libraries (all of them from System.* namespace though)

I managed to resolve the issue by adding following line to .csproj file

<PackageReference Include="Microsoft.NETCore.Targets" Version="3.1.0" PrivateAssets="all" />

The solution is proposed by Microsoft and documented here: https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1605 (example 2)

ivke
  • 536
  • 8
  • 18