Common.Logging.Core should reference mscorlib 4.0.0.0 instead of 2.0.5.0 in lib/net40.

[maboivin]

The NuGet package for Common.Logging.Core (at least v3.4.1) contains a net40 library that references mscorlib 2.0.5.0. It should reference mscorlib 4.0.0.0 like other components such as Common.Logging and Common.Logging.NLog*.

This is causing issues when used with Roslyn and also when used with StackExchange.Precompilation.Build.

[hsorbo]

I think this is the reason it wont compile under CPS/net4* of .net core 3.0: dotnet/wpf#1451

[gigi81]

This issue is making my WPF build fail for the bug mentioned above. This is the ONLY dll I cannot update to use mscorlib 4 insteaf of 2.0.5.0.

References which depend on "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes" [].
    C:\Users\test\.nuget\packages\common.logging.core\3.4.1\lib\net40\Common.Logging.Core.dll
      Project file item includes which caused reference "C:\Users\test\.nuget\packages\common.logging.core\3.4.1\lib\net40\Common.Logging.Core.dll".
        C:\Users\test\.nuget\packages\common.logging.core\3.4.1\lib\net40\Common.Logging.Core.dll
        C:\Users\test\.nuget\packages\common.logging\3.4.1\lib\net40\Common.Logging.dll

C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): error MC1000: Unknown build error, 'Could not find assembly 'mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.' 

[ds1709]

From dotnet/wpf#1451. Assumes I have same problem with Microsoft.Bcl.Async. Assemblies in this package depends from mscorlib 2.0.5.0. And I'm trying to use async/await in net40 project. It was all fine before I updated my project to SDK format (Microsoft.NET.Sdk.WindowsDesktop).

[snakefoot]

Can always use this custom nuget-package from this PR: #176

[gigi81]

@snakefoot that package in #176 is not signed and also it is the nlog one not the core one.

[snakefoot]

That is the problem with OpenSource projects. They only work as long someone thinks it is fun. You can always fork and compile with your own strong-sign-key.

[gigi81]

@snakefoot there would be no problems if the snk key was published #11
signing with your own key is pointless unless you re-build all dlls that link to this library. only here on github we are talking about 7.2k projects...

[snakefoot]

Can understand your frustration. But unless you have a time machine so you can fix the past. Then I think you have to say "thank you for the fish" and move on.

[gigi81]

@snakefoot I quite don't follow. are you a maintainer here?
of course we are grateful for the work. nobody is asking to fix the past. I just need the key to fix it myself.

[snakefoot]

Nope not a maintainer or janitor. Just aware that this project has very few updates and people are moving on.

[snakefoot]

Btw. when using NetCore then strong-naming is no longer that important, and GAC is no longer available. So you could consider making a pure NetStandard-build without strong-name-key.

.NET Core don't have strict assembly loading and removes the main downside of strong naming.

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

[snakefoot]

Have attached custom build nuget-packages without strong-name-key, that can be used for NetCore3 projects:

Common.Logging.Core.3.4.2.nupkg.zip
Common.Logging.3.4.2.nupkg.zip

Remove .zip extension and upload to your own local nuget-repository.