Support lower versions of netstandard

[fredrikhr]

Currently CLU targets either full .NET Framework 4.5 or the new .NET Standard 2.0.

The advice from Microsoft for library authors is to target the lowest version of .NET Standard that you can get away with.

To support CLU on more .NET platforms out of the box, it would be better to see if lower versions of .NET Standard can be targeted.

[fredrikhr]

PR #6 manages to target netstandard1.6 without any changes to the CLU code.

I noticed that even netstandard1.3 is possible except for the one call to System.AppContext.GetData in the DotNetExe class.

downgrading the dependency to netstandard1.3 would give us a significantly larger reach, and make it possible for many more application developers to make use of the library.

[natemcmaster]

I would be okay adding netstandard1.x, but want to keep netstandard2.0 as the recommended baseline for new apps. netstandard1.x has issues that netstandard2.0 fixes.

[fredrikhr]

@natemcmaster Just to clarify: You don't see other library authors consuming the CLU and you want to force people consuming CLU to target netcoreapp2.0?

Hmm... that is an interesting point. Even though I don't agree, but I can see the argument. On the other hand, if I really needed netstandard1.3 I'd just fork.

My argument is as follows: AFAIK targeting a lower netstandard does not give you a lower version of the netcore runtime libraries, it just reduces the number of API's the compiler is willing to compile against. Meaning: if you have the newest and latest of the .NET runtime installed (be it Xamarin, Mono, full .NET Framework or the .NET Core Runtime or sth. else) all the new security features will be active and running even though you consume a library targeting netstandard1.0.
That also means, unless there are specific security or performance issues in the code in this repo it is up to the runtime, to properly, efficiently and securly implement the APIs our library is consuming.

So from that reasoning, I'd say that lowering the netstandard target is always preferable if you can get away with it. In this case, we can get away with it.

Please correct me where I am wrong.

[natemcmaster]

To clarify, I'm saying I'd be okay if the package targeted these frameworks:

• net45
• netstandard1.x
• netstandard2.0

I'm fine adding a netstandard1.x target, but I don't want to remove netstandard2.0.

[fredrikhr]

@natemcmaster No, that would not accomplish anything useful. Targeting both net45 and netstandard2.0 make sense, since there are parts in both API sets where these two do not overlap.

netstandard1.x however is an actual proper subset of netstandard2.0. So having both targets is really superfluous when there is no code difference (like in the case if we'd target netstandard1.6).

But what do you loose by changing the target from netstandard2.0 to netstandard1.6? PR #6 proves that there is absolutely no difference? (Except for netstandard1.6 having a greater reach than netstandard2.0.)

[natemcmaster]

The reason I want to keep ns2.0 is not about the API surface. Rather, it's about packaging and dependency graphs. NETStandard2.0 has better build and restore times, fewer dependencies, and avoids a few minor bugs in how NuGet restores ns1.x PackageReferences in netcoreapp2.0 projects. I recommend reading this short thread for more details on the kinds of issues I want to avoid. JamesNK/Newtonsoft.Json#1423

[fredrikhr]

@natemcmaster Oh! I did not know that. Okay, then everything makes perfect sense. Thanks for pointing that out to me :)

[natemcmaster]

Fixed in 2.0.1. Thanks for the contribution @couven92 !

https://www.nuget.org/packages/McMaster.Extensions.CommandLineUtils/2.0.1