K4os.Compression.LZ4 icon indicating copy to clipboard operation
K4os.Compression.LZ4 copied to clipboard

Implicit reference to System.Runtime.CompilerServices.Unsafe appears to cause wrong version to be selected

Open gibbed opened this issue 2 years ago • 1 comments

Description

The implicit package reference seems to be causing VS to pick an older version 4.5.3 of System.Runtime.CompilerServices.Unsafe on newer NuGet releases (after 1.2.6) at least with .NETFramework,Version=v4.5 and .NETFramework,Version=v4.6.

This causes a type loading error.

The relevant commit that introduced this issue appears to be https://github.com/MiloszKrajewski/K4os.Compression.LZ4/commit/a6a75805493523ab0613b8c3a54f1b882c01651d.

To reproduce

Attempting to use the library from NuGet package versions 1.2.12, 1.2.13, 1.2.15, or 1.2.16.

Expected behavior

No issues.

Actual behavior

A type loading exception will be thrown.

System.TypeInitializationException: 'The type initializer for 'K4os.Compression.LZ4.Engine.LL' threw an exception.'

FileLoadException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

System.Runtime.CompilerServices.Unsafe for version 4.5.3 gets copied to the output path of the project.

Environment

  • CPU: AMD Ryzen 9 3900X (64-bit)
  • OS: Windows 10 Pro (21H2)
  • .NET: .NET Framework 4.5, 4.6
  • LZ4: 1.2.12, 1.2.13, 1.2.15, 1.2.16

Additional context

Explicitly installing the NuGet package for System.Runtime.CompilerServices.Unsafe, version 5.0.0 (possibly 6.0.0 too but I didn't try it) works around this problem. I'm not sure if this is the intended path, I didn't see it mentioned in the README.

gibbed avatar Jun 28 '22 02:06 gibbed

I can confirm the problem. This System.Runtime.CompilerServices.Unsafe is a PITA. It was explicitly referenced, but for new .NET Core it is built-in so referencing it was causing conflicts sometimes, so I removed it and trusted .NET to pick the right one. Now I can see it cannot be trusted.

So, it will return as explicit, but in the meantime just add explicit reference to your project.

MiloszKrajewski avatar Jul 04 '22 11:07 MiloszKrajewski

Hopefully sorted out in 1.3.0-beta

MiloszKrajewski avatar Nov 04 '22 22:11 MiloszKrajewski

Finally fixed in 1.3.3-beta. Tested with: net461, net48, netcore20, netcore31, net6 Check this

MiloszKrajewski avatar Nov 06 '22 21:11 MiloszKrajewski