Drop netstandard1.6 and netcoreapp1.1

[TheAngryByrd]

Description

With logary dropping support for netstandard1.6 haf/expecto@6429c66 and talking with people in the community we should just drop netstandard1.6 and netcoreapp1.1.

Error messages, screenshots

N/A

Failing test, failing github repo, or reproduction steps

N/A

Expected Behavior

N/A

Known workarounds

N/A

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version: master

[rmunn]

The first time I tried to use MiniScaffold to start up a project, I had a little bit of trouble with getitng the dotnetcore1.1 SDK installed on my Linux dev machine, since MS no longer releases a Linux package for the dotnetcore1.1 SDK on current versions of Linux. My choices were to go back to an older version of Linux, or to install the dotnetcore 1.1 SDK by hand. I chose the latter, and it all worked.

I think my experience is another argument in favor of dropping netstandard1.6 and netcoreapp1.1 from the default template. If anyone still needs them, adding them is as simple as editing two .fsproj files and rerunning the build. So it's not a great burden to anyone who needs netcoreapp1.1, and it lowers the barrier to entry for people just getting started with .Net Core development.

[TheAngryByrd]

Lots of other popular libraries have dropped support for it like Argu, Expecto, Giraffe, Suave, Httpfs

[rmunn]

The fact that three of those five projects you cite are (or were) maintained by Henrik Feldt shows just how prolific and active an F# coder he is. I'm seriously impressed by that guy. 😄

But since most of them are (as I understand it) now actively maintained by other people, that means that those projects dropping dotnetcore1.1 also isn't just one man's opinion, so it can be taken as broadly representative. In short: I'm in favor of dropping it from the MiniScaffold also.

[Tarmil]

I agree. As another data point, when porting WebSharper to .NET Standard we went straight for netstandard2.0.

[wallymathieu]

I think just dropping netcoreapp1.1 should not be a big issue. Why drop netstandard1.6?

[wallymathieu]

Giraffe depends on infrastructure that requires netstandard2.0.
Argu, Expecto and Suave are intended for running as executables (and less likely to actually care about other platforms than server side code) might probably be less of a contentious issue.
Httpfs never had support for anything lower than netstandard2.0 from what I can see from nuget. So it might be that they need to use things not part of netstandard1.6.

[TheAngryByrd]

Is there a way to tell the project system to have netcoreapp2.0 test netstandard2.0 then netstandard1.6? I actually have no idea how which app framework knows which library framework to choose when both have multitargeting enabled.

[wallymathieu]

Well, the easiest thing would be to start out with netstandard1.6 and then bump it if you need to. That way you can run the tests on netcoreapp2.0 without worrying. And if a library bumps, then it can be their decision to remove support for it.

If you really want to test a library built against netstandard1.6 and netstandard2.0 you would need some msbuild hacking to have it working. Perhaps a parameter to the build that disables netstandard2.0 or overrides it:

<TargetFrameworks Condition=" '$(TestTargetBuildFramework)' == '' ">netstandard1.1;netstandard1.3;netstandard2.0</TargetFrameworks>
<TargetFrameworks Condition=" '$(TestTargetBuildFramework)' != '' ">$(TestTargetBuildFramework)</TargetFrameworks>

[TheAngryByrd]

More datapoints. 4.0 of Npgsql has dropped netstandard1.3 and so did "netcore" of Eventstore

[wallymathieu]

We use netstandard1.6 for most of our internal libraries. For some projects we use EF so we have to bump to netstandard2.0. Some internal libraries that are pure c# without bells and whistles we actually use netstandard1.3 (but that's not so common).

[ScottHutchinson]

Version 0.8.0 seems to have a mismatch between src and tests projects:

src:
netstandard2.0;netstandard1.6;net461

tests:
netcoreapp2.0;netcoreapp1.1;net461

Shouldn't tests have netcoreapp1.6 instead of netcoreapp1.1 ?

[wallymathieu]

Has there been a release of netcoreapp1.6? From what I can see from the docs, netstandard1.6 is still compatible with 1.0: dotnet standard versions

[ScottHutchinson]

@wallymathieu Looks like you're right. It appears that netcoreapp should always be either netcoreapp1.0 or netcoreapp2.0 then. But there will be a version 2.1: https://github.com/dotnet/core/blob/master/roadmap.md#technology-roadmaps

[wallymathieu]

looks like there is a v1.1.6

[wallymathieu]

I think the paket guys know more about the weirdness with all of these framework tags. So perhaps someone from there could point in the right direction.

[TheAngryByrd]

We've already had to remove netcoreapp1.1 from the tests due to Expecto.

And David Fowler is calling for people to move to netstandard2.0.

https://twitter.com/davidfowl/status/1008453902058917888

[wallymathieu]

Sounds like reason enough to drop it.

[TheAngryByrd]

Closed in #93