Port to .NET Standard

[nbarbettini]

This PR makes the project compatible with .NET Standard/.NET Core. You should be able to open and build the new solution with Visual Studio 2017 (Community is fine), or build the project on other platforms with the dotnet tooling.

Here's what I changed:

• Removed nuget and nuspec. dotnet pack will produce the package now!
• Targeted .NET Framework 4.5 and .NET Standard 1.3. netstandard1.3 will make this package compatible (see the table) with .NET Framework 4.6+, .NET Core 1.0+, UWP, etc. If Downgrading target framework version to .NET 3.5 #71 is merged, then it should be possible to target .NET Framework 3.5 with the same approach.
• Moved the tests that require additional dependencies (ServiceStack and System.Web) into a new project. The main test project (now JWT.Tests.Core) is compatible with .NET Core, while JWT.Tests.NETFramework targets the full .NET Framework (because those dependencies are not compatible with .NET Core).
• Moved the test data that is used by multiple tests into a shared Common project.

All the tests pass! 😄

[nbarbettini]

Note: I left the JSON.NET dependency at 9.x. There's a new major version, but I figured that would be better suited for a separate PR.

[abatishchev]

Awesome! Let me take a closer look once I reach a desktop computer.

Meanwhile can you educate me on target frameworks and net standards. Per #70 and #71 we may want to target .NET 3.5. is it possible with Core?

[nbarbettini]

Sure: .NET Standard is the new way of creating portable libraries (it replaces PCLs). When you target a version of .NET Standard (1.2, 1.3, etc), you get an API surface area that is common across multiple platforms. Higher = more APIs = less platforms. So, a library targeting netstandard1.0 has the least APIs available, but is compatible with the most platforms.

You can think of .NET Standard as an interface, which is implemented by the actual frameworks: .NET Framework ("full" .NET), .NET Core, Mono, etc.

This table shows the compatibility matrix. For example, .NET Standard 1.2 is implemented by .NET Framework 4.5.1+ and .NET Core 1.0+. The lowest we can target is 1.3, because the System.Security.Cryptography.Csp package requires 1.3.

Tl;dr - packages created now and in the future should target some level of .NET Standard, preferably the lowest level that still includes the API support it needs. Then it'll be compatible with .NET Framework, .NET Core, future versions of Mono/Xamarin, future frameworks, etc.

[nbarbettini]

Re: .NET 3.5 (To add some more complexity to the topic... 😄 )

You'll notice that the table I linked to only shows .NET Framework down to v4.5 (which implements .NET Standard 1.0 and 1.1). This means that a library built to target netstandard1.1 would be usable in a .NET Framework 4.5 project, for example.

For .NET Framework compatibility <4.5, you have to "multi-target" your project and build a separate binary for those framework versions. It's confusing at first, but it works. In this PR, I targeted netstandard1.3 and .NET Framework 4.5. We should be able to drop that down to .NET Framework 3.5 without any problems. I'll test it in a bit.

[nbarbettini]

See my new commit - this should now be compatible with:

• .NET Framework 3.5+
• .NET Standard 1.3+ (.NET Core, UWP, Xamarin)

I had to remove Lazy<> like #71.

[abatishchev]

Thanks for great explanation! I'm mostly old/full .NET guy. Got sick with all this PCL crap that don't want to touch it now. And don't have much need too.

Yes, let's target 3.5 in Full .NET mode and the lowest possible in NetStandard.

I was thinking to make few child packages: one that depends on Json.Net to remove this dependency from parent package, and now maybe one that depends on cryptography if this would allow to lower target NetStandard?

[nbarbettini]

No problem 👍 It took me a while to wrap my head around the new world. It's complex at first, but no more PCLs!

one that depends on Json.Net to remove this dependency

Who would use this? People who want to bring their own IJsonSerializer I guess?

[nbarbettini]

I could see some benefit of splitting the package up into child packages. I think that might be out of scope of the PR though, happy to address that in a separate one 👍

[abatishchev]

To discuss the split #76

[paddyfink]

Hello, I tried to use this library https://github.com/viniciusmelquiades/jwt which is a fork of this one but I got this message when I try to encode a jwt : You need to set a JSON serializer. You only need to do this once.
Does it have something to do with the IJsonSerializer you are talking about?

[abatishchev]

@paddyfink hi, please open another issue, will discuss it there.

[nbarbettini]

@abatishchev Any changes you need on this before merging? (other than resolving the nuspec conflict)

[abatishchev]

Hmm, is there a way it to work in VS2015? Currently I'm getting an error opening projects:

D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj : error : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj

D:\Projects\Open Source\Jwt-nb\tests\JWT.Tests.Common\JWT.Tests.Common.csproj : error : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. D:\Projects\Open Source\Jwt-nb\tests\JWT.Tests.Common\JWT.Tests.Common.csproj

D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj : error : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj

Or I just don't have the latest Core tooling installed?

[nbarbettini]

The new project format requires VS2017 as far as I know. I've been using the free Community Edition: https://www.visualstudio.com/downloads/

[abatishchev]

Bummer. And might be quite inconvenient not just to me but to other people too. Can you please double check? Should be a way to make it work in VS2015? I haven't heard this is a well-known limitation of new Core tooling. However still might be it.

[nbarbettini]

Yeah, unfortunately that is the case. The new project system (csproj tooling for .NET Core/.NET Standard) requires VS2017. However the project can still be built on the command line (without VS) using dotnet.

How do you want to proceed?

[abatishchev]

As I saw in other OSS projects her eon GitHub, I'm not alone in this kind of struggle. Let me install VS2017 on my machine, try and let you know, we'll merge it it. Can I ask for a favor and meanwhile resolve the conflicts?

[nbarbettini]

I rebased this against master. It should be totally up-to-date with the latest changes you pushed for v2.3. (If I missed something, let me know!)

I changed the version to 3.0.0-beta1.

[abatishchev]

Current status: installing VS 2017 :) Sorry to make you waiting on this.

[nbarbettini]

Sorry to make you waiting on this.

No problem at all, I've been too busy to look at it these past few days anyway. 😄

[abatishchev]

Can you please push the branch to this repo rather then yours? Or we'll have to recreate the pr?

[abatishchev]

Yes, seems so. I can change the base but can't change the source.

[abatishchev]

I'm asking because GitHub (at least to my knowledge) makes in non-trivial to clone source repo/branch where the pr from created from.

[abatishchev]

I got it https://github.com/nbarbettini/jwt/tree/netstandard but again it wasn't trivial like a direct link from pr's page

[nbarbettini]

Yeah, it's a little awkward. AFAIK the best way to checkout a remote fork PR is to check out that repo.

[abatishchev]

Looks good!
Just few things annoys me (unrelated to the changes):

• Had to restart VS so NuGet could properly restore packages (usual thing)
• StyleCop warning "Missing XML comment for publicly visible type or member". I can't ask you to spent time on this but not willing to spent my time either, hate to do this :)

[abatishchev]

Should we rename/lower-case JWT.Tests.NETFramework to NetFramework?

[abatishchev]

Yay! Thanks a lot for this work!!

[nbarbettini]

StyleCop warning "Missing XML comment for publicly visible type or member"

I think it's only a few members that need XML comments. I can add them later. 👍

Should we rename/lower-case JWT.Tests.NETFramework to NetFramework?

Doesn't matter much, but "NETFramework" is/was used in the context of TFMs.