netstandard support?

[xied75]

Dear Team,

Just trying to nuget SharpZipLib.Portable into my PCL (targeting UWP, NET46, and ASP.NET Core 1.0), then I got error msg like this:

SharpZipLib.Portable 0.86.0.3 is not compatible with DNXCore,Version=v5.0.
Some packages are not compatible with DNXCore,Version=v5.0.
SharpZipLib.Portable 0.86.0.3 is not compatible with DNXCore,Version=v5.0 (win7-x86).
Some packages are not compatible with DNXCore,Version=v5.0 (win7-x86).
SharpZipLib.Portable 0.86.0.3 is not compatible with DNXCore,Version=v5.0 (win7-x64).
Some packages are not compatible with DNXCore,Version=v5.0 (win7-x64).

Any plan to extend the support?

[McNeight]

Dong,

The package you are using is currently a fork of SharpZipLib by @ygrenier at https://github.com/ygrenier/SharpZipLib.Portable

At the moment I am focused more on cleaning up the existing code and bug fixing, rather than adding new features. Hopefully soon, we can take a look at incorporating those features into our project.

-Neil

[xied75]

Thanks for clarify that. And I'll take the chance here to edit a bit my request: once you finish the spring clean, it will be great to able to support coreclr/corefx (or the new name they call it: netstandard). :)

[tdctaz]

I too would like to add a vote for netstandard support, are there any plans for adding support for it?

[justdmitry]

+1 for netstandard support.

@xied75 rename issue please (there is no more dnx, dotnet and netstandard are released)

[xied75]

Shall I propose a mini hackathon to get this going? I'm sure Neil is pretty much occupied by his work, if nobody volunteers then this would never happen.

[McNeight]

@xied75
Would it make more sense to integrate the SharpZipLib.Portable fork into the main repository first, or would you rather start from the main repository first?

-Neil

[xied75]

@McNeight Thanks for asking.

From my understanding, Yan Grenier @ygrenier mentioned in his fork Readme, that he did "remove" a bunch of things from base when he did his port. My feeling is that to merge these back wouldn't be a simple task and also it serves no purpose anymore, since his port is not netstandard ready as well. Unless we are thinking about very rare legacy requirements, having the main stream to retro support the port seems unnecessary. (I could be wrong)

Now talking about the main repo and netstandard, what I gathered is that Microsoft think given native zlib is everywhere where dotnet will be, the related classes in corefx will only wrap around calling zlib. They also mentioned in the past they have a pure managed implementation to fall back on where zlib is absent, I'm not sure where that part of source code is.

So in my opinion SharpZipLib can target to be the best performing Pure Managed Implementation, without touching native zlib at all, and leave that to corefx.

Going forward I would like to see:
1, we can remove anything Java (legacy code, idiom, weird stuff)
2, we can continue to improve performance
3, we can utilize new features in dotnet (e.g. System.Buffers to avoid alloc very often, etc.)

[Bond-009]

+1 netstandard support would be fantastic

[shanestevens]

+1 dotnet core

[ViktorHofer]

The .NET Core team is currently looking into popular repositories which have potential for netstandard targeting. I forked the repository and migrated to netstandard1.3. There were a few lines of code that are wrapped around and #if net45 statement but I didn't really saw its usage anywhere? The migration went flawlessly, did I miss something or is the entire code already netstandard ready?

If support for net45 is critical than multi targeting would be an option. In that case assemblies for netstandard1.3 and net45 would be created. If support for net45 isn't that necessary than I would recommend to only target netstandard1.3, as net46 and above is supported in that case. More on that here: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

The test library is currently written in net45 and could be converted to net46 or to netcore2.0. The advantage of netcore2.0 would be, that the entire solution could be cross plattform. netcore1.1 isn't possible as BinarySerializer isn't supported < netcore2.0. The only problem with that is that nunit CURRENTLY does not support netcore. See here: nunit/dotnet-test-nunit#91.

@McNeight how should be proceed? You might want to contact me per mail, so that we can fasten up communication

[xied75]

@ViktorHofer When you say

looking into popular repositories which have potential for netstandard targeting

you meant help to get the repo work under netstandard is that right?

Something else you might also be able to offer help on? This repo is in the middle of switching license to MIT, #103, from what I see there, it's not complete 100%, suppose those people who contributed 1 line never turn up, how should this proceed legal-wise? Surely one line of code shouldn't tie the whole thing to GPL forever? You probably have access to legal people on this which we all lack.

nunit people is still in the middle to get runner work for netstandard, with all duly respect, I think switching to xunit is much easier than workaround, I can try to PR on this if you guys agree.

@McNeight here too with all respect, with some borrowed courage, I felt that this project probably can set up a Tech committee and involve more people with merge rights (as the Apache model goes, e.g. jgit, or maven), so that the wheel can turn a bit faster?

[ViktorHofer]

@xied75 regarding nunit: I would have also made the suggestion switching from nunit to xunit as it is used by huge repositories like corefx and coreclr but as their are a LOT tests written in nunit I thought the migration would take to much effort. Still if you would take the time for that I would definitely be happy. But who am I to decide? ;)

regarding your licensing concerns, maybe @danmosemsft can help?

[christophwille]

@xied75 design by committee sounds like a bad idea. But more maintainers: yes. That's what we definitely want once the redesign is done (relicensing I think is complete @McNeight).

[jiabiao]

.NET Core 2.0 added the support for referencing .NET Framework libraries and NuGet packages.
I try to reference v0.86 to .netcoreapp2.0 project. Creating and unpacking zip file works well on Linux.

It just needs to add a line of code

ZipConstants.DefaultCodePage = Encoding.UTF8.CodePage;

[christophwille]

netstandard1.3 is now officially supported

[ghost]

What version of the library do we need to run on .NET Core 3?

thanks - dave

[Numpsy]

The .NET Standard 2.0 build should work, so 1.0 or newer I think.