Move to .NET Standard 2.0

[bording]

@ethomson Here's my work to move us to using .NET Standard 2.0. I was able to clean up and simplify a lot of stuff because 2.0 is the first reasonable version to target.

[bording]

Looks like I've got some more fighting with the CI servers to do before I can get everything building. 😢

[Zoxive]

Does this only build with Preview? This would hurt contributions. Bigger wall for first timers.

[Zoxive]

Just need 17.3 now

[Zoxive]

Being that 2.0 is still preview should this wait till 2.0 is out?

[bording]

@Zoxive Yes, this does currently require the preview, but the final release is going to be here very soon.

[bording]

And now the CI builds are green!

Travis was failing because of SourceLink, though I'm not entirely sure why. Since we don't actually care about the artifacts from Travis, I went ahead and prevented it from running on Travis for now.

@ethomson This should be ready to go now!

[Foda]

Just a heads up: this won't be "fully" NET Standard 2.0 supported due to the use of ICustomMarshaler . I filed this issue while attempting to test this branch. It would be great to try and remove the use of this attribute somehow, but I wouldn't consider this to be a blocking issue.

[dazinator]

Does this mean you will be dropping support for netstandard1.3 ? Given that netstandard1.3 is implemented by a wider array of platforms, I am just curious what the gains that moving to netstandard2.0 gave?

Many libraries strive to do the opposite, i.e they start by targeting the latest netstandard, and then strive to get down to the lowest version of netstandard that they actually need, so that they can run on more platforms.

[bording]

Supporting netstandard1.3 was a bit of a hack, because this project requires lots of custom marshaling. The current code has a build-time generator to try and work around the lack of custom marshaling, but it's rather complex and too finicky for my liking.

Custom marshaling was added back to netstandard2.0, so I'd argue that 2.0 was the only version we should have been trying to support in the first place.

[dazinator]

@bording - makes sense. If this is released as a new major version (breaking change) then I can't imagine this would be much of a problem for people - because those that can't afford to lose compatibility would simply not upgrade. Not sure what branching strategy is used here (I typically use GitFlow), but I assume there is facility to release a hotfix for the older netstandard1.3 release, should the need arise.

[bording]

@dazinator The netstandard1.3 release has only been a prerelease package. there's never been a stable release that includes it.

[ethomson]

Seeing as we haven't done a release at all with any .NET Core support, I dont feel a significant obligation to 1.3 users. Am I wrong in this thinking?

[dazinator]

The netstandard1.3 release has only been a prerelease package. there's never been a stable release that includes it.

Seeing as we haven't done a release at all with any .NET Core support, I dont feel a significant obligation to 1.3 users. Am I wrong in this thinking?

Nope - you are quite correct, it was only ever pre-release functionality. I had assumed it was in a stable release but I was mistaken ;-)

[dazinator]

However it would be a shame to lose support for netcoreapp < 2.0.0 though.

For example, I am looking at using libgit2sharp in GitVersion for version stamping. I would like people to be able to version stamp their existing .netcoreapp1.0, 1,1 apps. I will now have to remain on the Preview of Libgit2sharp if I want this to be possible.

[dazinator]

I would like people to be able to version stamp their existing .netcoreapp1.0, 1,1 apps.

Let me re-phrase that. I would like to support people who are stuck using the older dotnet cli's (1.0.0, 1.1.0 etc) for their builds. The versions of dotnet cli before version 2.0.0 are all using netcoreapp < 2.0.0.

Anyway it sounds like a tradeoff for me to deal with, not anything that should impact you!

[bording]

Let me re-phrase that. I would like to support people who are stuck using the older dotnet cli's (1.0.0, 1.1.0 etc) for their builds. The versions of dotnet cli before version 2.0.0 are all using netcoreapp < 2.0.0.

I wonder how many people this would actually be, considering that the 2.0 SDK/CLI can also build netcoreapp1.0 as well, there's no real reason to stay on the 1.0 CLI.

[dazinator]

I wonder how many people this would actually be, considering that the 2.0 SDK/CLI can also build netcoreapp1.0 as well, there's no real reason to stay on the 1.0 CLI.

You would think. Sadly there are still reasons to remain on older CLI's. Having been using the dotnet cli since it's inception (used the dnx prior to that) there have been a number of times where breaking changes have been introduced and installing the newer CLI on an environment has broken all of the current builds. I am now a big fan of locking builds down to using specifc CLI versions - just to avoid future breaking changes being forced on us when newer CLI version is installed on the environment in future. Things like this for example cost us time and money: https://github.com/dotnet/cli/issues/5331

The way you "lock" a solution to an older CLI version is by adding a global.json file to the repository. Once this global.json file is present, you can install later versions of the dotnet cli on the environment and it won't impact that repository which will remain pinned to the specified CLI version.

I bet there are quite a few environments out there that also lock their tools down via a global.json just to ensure stability and that breaking changes aren't forced on them accidentally.

IMHO The decision my MS to automatically bind dotnet cli commands to the latest installed version of the CLI (irrespective of whether it's a new major version) is crazy. They should have pinned the solution to a particular Major version, allowing only minor updated and patch releases of the tooling to impact the repository - in accordance with a healthy respect for semver.

[Jaykul]

Yes, the libgit2sharp .NET Standard 1.3 package has only ever been a pre-release.
After all these months, people are probably wondering if this project's abandoned 😉

There was a similar discussion to this when NLog moved to 2.0, for what it's worth.

NET Standard 2.0 is still new enough that it's only really fully implemented on the very latest versions of ... everything. The .NET team is constantly repeating that "the lower the version [you support], the more platforms you can run on." But I can't find any reference at all which documents any actual hardware or OS platforms that still support only .NET Standard 1.x and not 2.0 -- even Xamarin.iOS and Xamarin.Android and UWP have added support for .NET Standard 2.0

In other words, if you don't like the ugliness required to support to lower versions, it seems to me that the only reason to stay on the lower API version would be to support old versions of tools ... but since you've never supported them before, it seems a moot point.

Disclaimer: All of my stuff has historically been on full Windows-only desktop framework, and most of it is migrating to .NET Standard 2.0 -- I just want something supporting any version of the .NET Standard to be released, so I can move to Standard so people stop asking me if my projects are abandoned... 😊

[ethomson]

Right. I'm reasonably convinced that 2.0 is probably the right version to support. I'll 👀 this and merge it soon. Thanks for your patience.

[ethomson]

🎉 Thanks for this, this seems like a really nice improvement and I'm really pleased to see some of the simplifications going on here. Sorry it took so long to review it, but ⚡️

[dvandervlag]

Hi all,

When do you expect to release the .netstandard 2.0 support? :)