Lz4frame fails to detect uncompressed blocks about lz4.frame HOT 8 CLOSED

I have made the standard project using lz4net.netcore.signed as reference. The NetFramework 4.7 x64 Application should be set to use PackageReference (instead of packages.config) or the nuget packages refered by LZ4.Frame won't be downloaded when compiling... (a bug about dotnet/standard#481)

from lz4.frame.

Thank you for reporting these issues, I will try to fix them.

I've known that lz4net has a successor. I don't know if the author is going to implement a complete LZ4 Frame solution. see: MiloszKrajewski/K4os.Compression.LZ4#3

from lz4.frame.

@vpenades Could you explain more about the net.standard / net.framework version mismatch (how to repro)? I tested installing the nuget package on a .NET Core console project, and installing the nuget package on a .NET Standard 1.3 lib project (then referenced by a .NET Core console project). Both will work and actually use LZ4.Frame.Std.dll & netstandard1.0\LZ4pn.dll.

from lz4.frame.

yes, the problem is also been reported here.

Basically, LZ4Net package contains multiple DLLs for different frameworks.

The Net Frameowork DLL has version 1.0.15.93 but the net standard DLL has version 1.0.0.0

If you create a net standard library FOO that uses LZ4Net, it will pull the net standard DLL, which has version 1.0.0.0, making your library require that version.

If later, you create a NetFramework 4.7 application, and you reference your FOO library, the package resolution system will pull the lz4net 1.0.15.93 DLL for net framework. BUT, your FOO library will still try to load a lz4.dll versioned as 1.0.0.0 and it will fail.

So, this dependency linking fails:

NetFramework 4.7 x64 Application -> NetStandard Foo Library Project -> lz4net package

It all happens because the DLLs inside lz4net have version numbers different than the package itself, which is a bug.

Also, the application project needs to be the "old style" csproj format, not the new simplified one. This also requires the application to add the LZ4net package directly, even if it's also referenced by the foo library.

from lz4.frame.

Is that to say, if I modified the nuget spec to use lz4net.netcore.signed for LZ4.Frame.Std, the problem will be solved?

The main reason I use lz4net for LZ4.Frame.Std is that it support from .NET Standard 1.3 to 2.x while lz4net.netcore.signed only support 2.x. However, if switching to this lib will fix the issue, I will just do it.

from lz4.frame.

Seems that the new generation of lz4net is comming soon, and this lib will be useless in the near future!

https://github.com/MiloszKrajewski/lz4net/blob/master/doc/compatibility.md

from lz4.frame.

I think we're in a transition period... Lots of developers thought that moving to net standard was about changing the project configuration... And they're discovering there's a lot more than that...

So until the dust settles, will be forced to dance with packages for a while... 😁

from lz4.frame.

The new nuget package is online and this problem should be solved...
If you still have this problem, feel free to re-open this issue.

from lz4.frame.