Migrate UnitsNet + Serialization projects to "VS2017-style" projects targeting netstandard1.0

[supermihi]

Overview

This PR resolves #255:

1. Adds a .NET core / "VS2017-style" project for UnitsNet.Serialization.JsonNet
2. Migrates UnitsNet.NetStandard10.csproj to current .NET core / "VS2017-style" toolset format (was necessary to get 1. running)
3. Adds a netcoreapp1.1 project for the serialization unit tests
4. Adds a solution UnitsNet.Core.sln that references only the abovementioned project that are compatible with dotnet core (and hence support cross-platform build).

Notes

The new csproj-Format is much more compact than the other and can be used for various target frameworks at once: I haven't included this yet because I only have a linux machine at hand right now so I cannot test, but using VS 2017 it should be possbile to add net35 and uap10 target frameworks to the respective .NetStandard10.csproj-files which would allow to remove all the other projects.

Further, since one now can build NuGet packages directly from a new-style csproj (using dotnet pack on the CLI or the "pack" option in VS 2017) the "boilerplate" of this repository could probably be further simplified.

Known Limitation

UnitsNet.Tests does not yet work with .NET core because it needs to be migraed to NUnit 3 first. I could not figure out (without a windows machine) how the code generation works, so I did not touch that test project yet. I'll be happy to help with the migration but wanted to await the feedback to this PR first.

[angularsen]

Wow, you put in some solid effort here. I'll need some time to review it, but I like the approach you go with here and simplifying things.

I must say, I gave a puny attempt at converting to MSBUILD 15 / VS2017 not long ago, but I was met with all sorts of trouble I could not make sense of at the time and my heart was just not in it to figure it out.
With this PR I see the light again :-)

[supermihi]

Thanks. Msbuild 15 is still a mess, especially when it comes to documentation, but it starts to improve slightly, and I had to dig through for another project anyway. ;)

Meantime I managed to test the setup using VS 2017 and add the "net35" target for both UnitsNet and the serialization project. The "uap" target for windows runtime should in theory als work, but gives an error, probably related to this.

[angularsen]

Cool. I just upgraded the NUnit3 stuff and fixed the compile errors.
Can you make me a collaborator on your fork? Then I can more easily push some changes your way.

https://github.com/anjdreas/UnitsNet/tree/pr/257-vs2017

This works:

dotnet restore UnitsNet.Core.sln
dotnet build UnitsNet.Core.sln

Currently trying to get tests running from command line using https://github.com/nunit/dotnet-test-nunit

[angularsen]

With your latest changes, I'm getting errors

  UnitsNet.NetStandard10 -> C:\Repos\unitsnet\Artifacts\Bin\Src\AnyCPU_Debug\netstandard1.0\UnitsNet.dll
C:\Program Files\dotnet\sdk\1.0.4\Microsoft.Common.CurrentVersion.targets(1111,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v3.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [C:\Repos\unitsnet\UnitsNet\UnitsNet.NetStandard10.csproj]
  UnitsNet.Serialization.JsonNet -> C:\Repos\unitsnet\Artifacts\Bin\Src\AnyCPU_Debug\netstandard1.0\UnitsNet.Serialization.JsonNet.dll
C:\Program Files\dotnet\sdk\1.0.4\Microsoft.Common.CurrentVersion.targets(1111,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v3.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [C:\Repos\unitsnet\UnitsNet.Serialization.JsonNet\UnitsNet.Serialization.JsonNet.csproj]
  UnitsNet.Serialization.JsonNet.Tests.NetCore -> C:\Repos\unitsnet\UnitsNet.Serialization.JsonNet.Tests\bin\Debug\netcoreapp1.1\UnitsNet.Serialization.JsonNet.Tests.dll

Build FAILED.

It seems related to this:
dotnet/msbuild#1333

It seems to me targeting .NET 3.5 is not supported by the dotnet CLI yet?

[angularsen]

Signing off for tonight 😴

[supermihi]

You now should be a collaborator on the fork. Regarding net35: Yes, doesn't seem to work with the "dotnet" command-line, but you can build the whole solution from within visual studio 2017, it will generate both the .NET 3.5 and .NET Standard 1.0 DLLs.

To build with the dotnet CLI, you have to specify the target explcitly: dotnet build -f netstandard1.0

[supermihi]

By the way, if I correctly read the .NET standard table, there's no need to build a DLL targeting win81, win10 or uap because they are compatible with .NET standard 1.0?

[angularsen]

You are probably referring to the UnitsNet.WindowsRuntimeComponent project?

It is a very special kind of beast, basically it imposes a lot of restrictions on the public API in order to be consumed by WinJS and C++ UWP apps. If I understand the table right, it does not address Windows Runtime Components in terms of netstandard - and it makes senses, since the restrictions are in addition to what .NET API surface you can expect.

https://docs.microsoft.com/en-us/windows/uwp/winrt-components/creating-windows-runtime-components-in-csharp-and-visual-basic

[supermihi]

Ok, I thought WinRT and UWP are more or less the same. According to this site, "you can consider [UWP] as an successor of the WinRT" ... so maybe one could consider dropping WinRT support in future versions anyway?

[angularsen]

I totally understand your confusion, Microsoft messed up the namings in a big way. WinRT -> UAP -> UWP.
Then they added Windows Runtime Component. This does not mean WinRT directly, but rather a component that can be consumed by any UWP flavor app (C#, javascript, c++).

So, people who write UWP apps in javascript can take a dependency on Units.NET and use it for conversions etc - directly from javascript. It's pretty cool on the technical side of things, but I'm not sure how widely used it is.

There are some sample WinJS/C++/c# UWP apps in the repo to test this.

• https://github.com/anjdreas/UnitsNet/tree/master/UnitsNet.TestApps.Uwp.JavaScript
• https://github.com/anjdreas/UnitsNet/tree/master/UnitsNet.TestApps.Uwp.WinJS
• https://github.com/anjdreas/UnitsNet/tree/master/UnitsNet.TestApps.Uwp.Csharp

[angularsen]

I created a new branch vs2017 on your fork, could you recreate the PR on that branch? It's a bit tricky to work on the master branch as I use that for other development.

https://github.com/supermihi/UnitsNet/compare/vs2017?expand=1

[angularsen]

Made a little bit of progress. Started rebuilding a build.ps1 script at the root dir, which uses dotnet CLI to regen code, build, test and pack nugets. It currently does all that for the serialization lib, but not yet for the main lib. There are some incompatibility in the test code across .NET Core and .NET Fx.

So far I've approached this by using .NET Core test projects for dotnet test, as the full framework test projects does not seem to work. I guess that's fine, but shouldn't dotnet CLI support both targets?

Anyhow, feel free to continue on this work. I'll see if I can find some time this weekend.

[supermihi]

As far as I understand, with dotnet you can run only netcoreapp projects, but perhaps it is possible to run the tests on .NET Framework with VS2017?