.NET Standard port

[ForNeVeR]

Description

This is based on your initial work in dotnetcore branch.

The main libraries are now targeting .NET Standard (1.0 and 1.6), and examples/tests are compiled against .NET Core 1.1.

See the commits for detailed descriptions of my changes. The porting was easy enough.

Impact

Closes #33, I guess?

Testing

• [x] I've tested the code on Windows
• [x] Linux testing is still required

Remaining issues

1. It seems that you was forced to disable some of the Unix-related features in your commit 958f07ae5ea551a121a2e96708a3bbec0c4a98be. Should we find a way to re-enable those?
2. The code was fully converted to .NET Standard/Core; I wasn't checking .NET Framework / Mono builds at all. Should we reenable them also? Or maybe just drop these and use .NET Standard?
3. I guess that the unit tests won't run in the new configuration; we'll need to fix Travis config (and probably add Appveyor?).

[elw00d]

Ow ! I've fixed the linux troubles with .NET Core just yesterday :) Will take a look and try to merge our changes

[ForNeVeR]

Fell free to contact me if you need any help with the PR or .NET Core.

I was too lazy to run the code on my Linux machine, but I can do that (and try to fix any issues we encounter) if that's necessary.

[elw00d]

committed my current state here https://github.com/elw00d/consoleframework/commit/91392e35bd20b1742cfd413d17955f8654ccdfb6 (tested on linux x64 only now)

may be we can try to use .net core 2.0 (since 2.0 was released anyway) ?

[ForNeVeR]

@elw00d well, let's discuss. First of all, to make sure we're on the same page, I'll describe my thoughts on the matter.

See, there're two distinct entities: .NET Standard and .NET Core.

• .NET Standard is the desired target for any libraries, because you can use .NET Standard assemblies from either .NET Framework or .NET Core applications. You can't directly execute .NET Standard assembly (e.g. you cannot write the application targeting .NET Standard); it'd designed only for library assemblies.
• .NET Core is the target for applications (and also for unit test projects). Assemblies written for .NET Core generally cannot be referenced from .NET Framework code (.NET Core 2.0 adds a big layer of compatibility, but my statement is still correct: generally that won't work).

When authoring libraries, there's a general recommendation to select the lowest version of .NET Standard you can, because it will allow more clients to use your library. E.g. if we write our code for .NET Standard 1.6, we will be able to reference it from Mono 4.6 (according to the compatibility matrix¹).

There's an additional reason why I currently have to stay on .NET Core 1.1 / .NET Standard 1.6: the tooling for F# on .NET Core / Standard 2.0 is still far from excellence. And I have plans to use ConsoleFramework from my cross-platform F# programs. So today I'd politely ask you to stay with .NET Core / Standard 1.x if possible.

Summary:

1. I suggest to use the lowest .NET Standard version we can for every project. I've already determined the minimal requirements (.NET Standard 1.0 for Binding and Xaml projects; .NET Standard 1.6 for ConsoleFramework itself). That leaves us with a NuGet package compatible with .NET Standard 1.6.
2. For unit tests and example projects you may use whatever you like, but I suggest to use .NET Core 1.1. Using .NET Core 2.0 would introduce minor inconvenience to me personally, because the IDE I favor (Rider) doesn't support .NET Core 2.0 yet. And I can't see why we need 2.0 features anyway.

¹ The compatibility matrix is known to provide outdated information sometimes, please keep that in mind. That fact shouldn't discard any general statements of this post.

[ForNeVeR]

@elw00d also I've seen your question regarding the diff between my and yours contents of Binding.csproj.

1. <TargetFramework> in my Binding.csproj is following my recommendations from the previous post.
2. You've noticed that you don't need the AgileObjects.NetStandardPolyfills package. Likely that's because .NET Standard 2.0 includes all the reflection APIs we depend on, while .NET Standard 1.6 doesn't include them (so we have to use polyfill that internally uses GetTypeInfo() etc.).

[ForNeVeR]

Alright, merged with your changes in the dotnetcore branch.

Now we need to check the code on both platforms and on both build modes (.NET Core and .NET/Mono).

[elw00d]

Thank you ! Works OK in linux. Merged here https://github.com/elw00d/consoleframework/commit/419080362d5d0ecb11acaa45fa4471a30340118a

Closing this PR

[ForNeVeR]

Okay, thank you.