Make .NET Framework fallback open-ended

When a developer references a NuGet package that doesn’t provide any assets for the current .NET platform, the SDK will fallback to try .NET Framework assets, provided the current .NET platform supports at least .NET Standard 2.0.

The fallback works by telling the NuGet selection algorithm “pretend I’m .NET Framework 4.6.1 so select me assets for that”. We determined that to be unfortunate and would like to change that to .NET Framework 5.0.

The rationale being:

• It will automatically work for all current and future 4.x releases
• We don’t plan on shipping another side-by-side release of the .NET Framework
• Given that this mapping is best effort and one way only, even if we do ship a 5.0.0, nothing bad would happen. Worst case, we have to bump the mapping to an even higher version.

Update

@nguerrera raised concerns regarding breaking people. So we generally want an algorithm that picks the “smallest” .NET Framework as that wouldn’t change the behavior from today or we add new versions of .NET Framework. So I propose instead of mapping it straight to 5.0 we do this:

AssetTargetFallback = net461;net462;net47;net471;net472;net48

/cc @weshaggard @ericstj @davidfowl @Petermarcu @dsplaisted @nguerrera

[terrajobst]

@joperezr

That’s a very good point and I’m glad you pointed this out. As @nguerrera said:

The whole episode of retroactively making things compatible with netstandard 1.5+, and thereby changing assets resolved with an sdk upgrade, still gives me nightmares…

👍 😱

@nguerrera

If we want assets for “lowest version of .NET Framework that succeeds” in general, then I think we need nuget changes, and that it would be expensive to implement, but I’m not 100% sure I have the AssetTargetFallback behavior exactly right in this analysis.

Couldn’t we just do this:

AssetTargetFallback = net461;net462;net47;net471;net472;net48

I understand that this is less ideal than implementing the actual logic, but given how often .NET Framework ships, this might be a good compromise. The “nice” thing about this is that adding new items to the right isn’t a breaking change as it would only make more scenarios work that previously would have resulted in no assets, so even if the SDK doesn’t ship exactly at the same time as the .NET Framework targeting pack, the worst that can happen is that customers complain that certain NuGet packages (i.e. the ones that target the latest version of the .NET Framework) aren’t consumable via the compatibility mode, which in general should be rare as packages under active development hopefully offer a .NET Standard asset anyway.

Thoughts?

[terrajobst]

Should the ordering go the other way? If an asset exists for both net48 and net461, should we actually prefer the net48 one?

@nguerrera already addressed the compat angle. But more importantly, the .NET Framework compat mode is best effort. If a package overs 4.6.1 and 4.8, presumably that’s because it uses more features in the 4.8 binary. The 4.6.1 binary has a higher chance of working in .NET Standard compliant implementations though, which is why it still makes sense to prefer them over the later assets.

As far as the perf riks goes: assuming the perf hit only slows down error cases, then I’m OK with that, unless the result is unbearable.