Nlog: "The package 'NLog' tried to add a framework reference to 'System.IO.Compression' which was not found in the GAC. This is possibly a bug in the package."

[sandersaares]

Type (choose one):

• Bug

NLog version: (e.g. 4.2.3)
5.0.0-beta09

Platform: .NET Framework 4.7

Issue

When installing the NuGet package of 5.0.0-beta09 to my .NET Framework 4.7 unit test project, I get the following error:

Attempting to gather dependency information for package 'NLog.5.0.0-beta09' with respect to project 'Tests.NetFramework', targeting '.NETFramework,Version=v4.7'
Gathering dependency information took 662,02 ms
Attempting to resolve dependencies for package 'NLog.5.0.0-beta09' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'NLog.5.0.0-beta09'
Resolved actions to install package 'NLog.5.0.0-beta09'
Found package 'NLog 5.0.0-beta09' in 'C:\Source\Toolkit\packages'.
Package 'NLog.5.0.0-beta09' already exists in folder 'C:\Source\Toolkit\packages'
Install failed. Rolling back...
Package 'NLog.5.0.0-beta09' does not exist in project 'Tests.NetFramework'
Executing nuget actions took 1,1 sec
Failed to add reference. The package 'NLog' tried to add a framework reference to 'System.IO.Compression' which was not found in the GAC. This is possibly a bug in the package. Please contact the package owners for assistance.
  Reference unavailable.
Time Elapsed: 00:00:01.7830560
========== Finished ==========

I thereby contact the package owners for assistance!

[sandersaares]

Manually installing System.IO.Compression from NuGet beforehand appears to work around this issue.

[sandersaares]

I noticed a build warning after doing the above. Possibly related?

4>    There was a conflict between "System.Security.AccessControl, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Security.AccessControl, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
4>        "System.Security.AccessControl, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "System.Security.AccessControl, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not.
4>        References which depend on "System.Security.AccessControl, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [C:\Users\saares\.nuget\packages\system.security.accesscontrol\4.0.0\ref\netstandard1.3\System.Security.AccessControl.dll].
4>            C:\Users\saares\.nuget\packages\system.security.accesscontrol\4.0.0\ref\netstandard1.3\System.Security.AccessControl.dll
4>              Project file item includes which caused reference "C:\Users\saares\.nuget\packages\system.security.accesscontrol\4.0.0\ref\netstandard1.3\System.Security.AccessControl.dll".
4>                C:\Users\saares\.nuget\packages\system.security.accesscontrol\4.0.0\ref\netstandard1.3\System.Security.AccessControl.dll
4>        References which depend on "System.Security.AccessControl, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [].
4>            C:\Users\saares\.nuget\packages\system.threading.accesscontrol\4.0.0\ref\netstandard1.3\System.Threading.AccessControl.dll
4>              Project file item includes which caused reference "C:\Users\saares\.nuget\packages\system.threading.accesscontrol\4.0.0\ref\netstandard1.3\System.Threading.AccessControl.dll".
4>                C:\Users\saares\.nuget\packages\system.threading.accesscontrol\4.0.0\ref\netstandard1.3\System.Threading.AccessControl.dll
4>            C:\Users\saares\.nuget\packages\system.io.filesystem.accesscontrol\4.0.0\ref\netstandard1.3\System.IO.FileSystem.AccessControl.dll
4>              Project file item includes which caused reference "C:\Users\saares\.nuget\packages\system.io.filesystem.accesscontrol\4.0.0\ref\netstandard1.3\System.IO.FileSystem.AccessControl.dll".
4>                C:\Users\saares\.nuget\packages\system.io.filesystem.accesscontrol\4.0.0\ref\netstandard1.3\System.IO.FileSystem.AccessControl.dll
4>            C:\Users\saares\.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\\ref\mscorlib.dll
4>              Project file item includes which caused reference "C:\Users\saares\.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\\ref\mscorlib.dll".
4>                C:\Users\saares\.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\\ref\mscorlib.dll
4>    C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1987,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.

[luigiberrettini]

Same happens to me

[osoykan]

same here

[304NotModified]

Does anyone know how to fix this?

[sandersaares]

I tried to take a look but I do not understand how the NuGet package is even generated. The published NuSpec has comments along the lines of **BREAKING CHANGE in beta08 !!** but I cannot find such text anywhere in the source tree and GitHub search here also gives me nothing.

Can you provide some relevant code references so this can be investigated?

[304NotModified]

I tried to take a look but I do not understand how the NuGet package is even generated. The published NuSpec has comments along the lines of BREAKING CHANGE in beta08 !! but I cannot find such text anywhere in the source tree and GitHub search here also gives me nothing.

The nuget package description is edited on nuget.org. A bit easier to maintain descriptions.

[sandersaares]

Opened https://github.com/NuGet/Home/issues/5812 regarding original post and https://github.com/NuGet/Home/issues/5813 with regard to the assembly reference warnings. These seem like tooling issues, really.

[304NotModified]

Thanks!

I'm also unsure how to fix this. I'm now one holiday, will try to check this before the end of next week

@snakefoot any idea?

[snakefoot]

Very strange that NET 4.7 attempts to use the dependencies of NetStandard.

NET47 should use the closest match, which is NET45, and not NetStandard. Almost sound like https://github.com/NuGet/Home/issues/4165

[snakefoot]

@sandersaares + @osoykan Are you using latest VS2017 (Version 15.3.3) ?

[snakefoot]

Have now removed the following unneeded package-references from the NLog 5-project (See #2269):

    "System.IO.FileSystem.AccessControl": "4.0.0",
    "System.Security.AccessControl": "4.0.0",
    "System.Threading.AccessControl": "4.0.0"

But I think these "conflict" warnings are just telling you, that your current target-framework is using a higher version of the specified package-references. Which is okay for NetCore2/NetStandard2 projects as they have higher library versions than NetStandard15

[snakefoot]

Looks like something has been fixed for NLog in VS2017 15.3.3 (Released August 29th):

https://developercommunity.visualstudio.com/content/problem/96301/vs-153-update-causes-package-is-not-compatible-for.html

[osoykan]

@snakefoot,

It was not 15.3.3, it was 15.3.2 i think. i'll give a try with new version of visual studio, hope they fixed this.

[snakefoot]

But it actually looks like these warnings are "expected", and should be handled manually with binding-correction (See solution):

https://developercommunity.visualstudio.com/content/problem/95070/could-not-load-file-or-assembly-systemruntime-vers.html#reply-98340

Still not sure why you get conflict-warnings when targeting Net462 and Net47 as they should use the Net45-nuget-lib (Have tested it works without warnings for me). Maybe it is because your Net47-project is depending on a NetStandard-library that depends on NLog? (In this case binding correction is apparently needed).

[sandersaares]

I confirm that I see no change in behavior after upgrading to latest VS 15.3.3. Both problems still occur (the IO.Compression thing and the reference conflict warnings).

[snakefoot]

@sandersaares Can you edit your original starting post, and attach an example project with dependency on NLog 5.0 BETA09, which reproduces the problem with IO.Compression ?

The reference conflict warnings are meant to be there, when mixing full netframework with netstandard.

[sandersaares]

I would dispute that "are meant to be there" but I assume you just meant to say "are there due to tooling defects" which seems to be true.

I do not have on hand a solution to repro the problem but the steps are very simple:

1. Create a new .NET Standard 2.0 library project.
2. Add a new .NET Framework 4.7 unit test project.
3. Add a reference to the class library in the unit test project.
4. Attempt to install NLog 5.0.0-beta09 into the unit test project.
5. Get error about S.IO.Compression

[snakefoot]

@sandersaares Yes I can reproduce the issue. If I manually add the following references to the test-project before installing NLog as nuget, then it works fine:

System.IO.Compression
System.IO.Compression.FileSystem

I think the correct solution is to add the following option to your test-project before installing NLog-nuget-package (Should be done for all full NetFramework-projects that references NetStandard-projects):

<RestoreProjectStyle>PackageReference</RestoreProjectStyle>

See also: https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx

[304NotModified]

@snakefoot is there something we could do about this?

[snakefoot]

No I think it is working as intended. It is just tooling noise, because people are trying to use NetStandard assemblies from NetFramework projects. Nlog 4.5 should make less noise, and people will learn to configure their NetFramework-project correct, before adding dependency to NetStandard assemblies.

[sandersaares]

because people are trying to use NetStandard assemblies from NetFramework projects

Using .NET Standard assemblies from .NET Framework is a normal scenario and should not be causing "tooling noise".

Now I do suspect it may just be a fault of tooling bugs and there may indeed not be much that can be done here from NLog side but you cannot possibly call this working as intended. The issue should be reported to tooling authors (if not already) and hopefully fixed.

The issues I reported above with Microsoft seem to have not caught much interest from Microsoft so I ran out of ideas for now, though.

[snakefoot]

Are you getting any noise when you have configured RestoreProjectStyle correctly for the NetFramework-project to support NetStandard dependencies?

[sandersaares]

I reject the claim that there is a "correct" RestoreProjectStyle for such a situation. All such configuration values are correct. Yes, there may be configuration changes that work around issues but that does not make them "correct", it makes them temporary workarounds.

[snakefoot]

Im guessing that is your way of saying, that the NLog package is working, and you are going to create a new issue for Microsoft to fix Visual Studios way of consuming NetStandard packages in full NetFramework projects

[304NotModified]

As NLog 4.5 now supports (practically) all the platforms added in NLog 5 - without breaking changes - NLog 4.5 should be used instead of NLog 5.

As this is an NLog 5 issue, we will close this. If this is still an issue in NLog 4.5, please create a new issue and reference to this one, thanks!

[sandersaares]

I confirm that using 4.5-rc3 appears to result in successful package installation in my scenario.

I look forward to stable release of 4.5

[304NotModified]

Thanks for the confirmation!

[programatix]

I'm targeting NetFramework 4.7.2 where the System.IO.Compression version is 4.2.0. However NLog marked its dependency for System.IO.Compression version is 4.0.0. Due to this, the Visual Studio Installer (setup generator for Visual Studio 2017) always include both System.IO.Compression version 4.0.0 and 4.2.0 into the generated setup output.

[snakefoot]

@programatix Please create new issue because this one is closed. Sounds like a bug in the Visual Studio 2017 nuget-package handling (And not in NLog). Please describe what version of VS2017 you are using when you create new issue (Make sure you are using latest).