Standard: Consider a more open-ended compatibilty mapping with .NET Framework

[ericstj]

@Petermarcu suggested that we might desire a more open ended behavior rather than what we currently have (.NET 4.6.1). Opening this on his behalf.

[weshaggard]

@Petermarcu @ericstj can you guys elaborate a little further what you mean by open-ended?

[ericstj]

Today the SDK only allows you to "try" to use a net461 or older package.
https://github.com/dotnet/sdk/blob/a8cf9e78eeb14852a7bf97b344731d9734b5d877/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets#L146

What would it mean to allow newer net4x frameworks to be used? So if a package only supported net462 why not allow someone to try and use it? What about net47? etc

[joperezr]

Can’t you still do it if you want by using the Imports clause?

[ericstj]

Sure, that's the same mechanism that's used by the SDK, the question is what should the default be.

[terrajobst]

I'm very supportive, yes we should do this. My suggestion would be to map it to .NET Framework 5.0.0. Given that we'll never produce another side-by-side release of the .NET Framework, this will automatically work for all current and future 4.x releases. And given that this mapping is best effort and one way only, even if we do ship a 5.0.0 nothing bad will happen.

@weshaggard @ericstj @davidfowl Any objections?

[ericstj]

This sounds reasonable. You may want to think about where that change takes effect: will it happen with a new SDK version, a new TFM, a new project template? The most permissive would be a new SDK with some way to rollback to the old behavior if folks are broken.

[weshaggard]

Sounds reasonable.

[terrajobst]

@nguerrera @dsplaisted

It looks like this is handled in the .NET SDK here. The suggestion is to change net461 to net5.

Should I file a bug in the SDK repo for this?

[dsplaisted]

@terrajobst Yes, file a bug in the SDK to change that value.

[terrajobst]

Filed https://github.com/dotnet/sdk/issues/2425.

[joperezr]

Joining a bit late this conversation, but wouldn't it be best if we first try net461 in case there is one? For example, there is a package with a net47 and a net461 implementation. Previously we would have used the net461 one, but if we make that change I believe we will now grab the net47 one, when we know that the net461 is more likely to be compatible. Should we add some special logic for that case?