Simplify .NETFramework tfms by avoiding the "-windows" RID

[ViktorHofer]

Libraries which target .NET Framework usually have rid agnostic tfms, i.e. net461. If the library targets netstandard2.0-windows as well, the .NET Framework tfm must be rid specific, as rid specific .NET Framework apps would otherwise pick the .NETStandard asset over the .NETFramework one (based on the RID compatibility rules). There is yet another reason that requires .NETFramework tfms to be RID specific, which is when a project P2Ps other projects which are rid-specific. Without the RID specific .NETFramework tfm, a compatible .NETStandard asset would be picked instead.

NuGet doesn't support setting a TargetPlatform in the TargetFramework alias when targeting .NETFramework or .NETStandard. Any such tfms in dotnet/runtime are currently leveraging a hack that strips the TargetPlatform / TargetFrameworkSuffix away during restore and packaging (as NuGet Pack uses the project.assets.json file). For any project that includes a RID specific .NETFramework or .NETStandard tfm, a NuGet.config file must be present next to the solution file so that Visual Studio doesn't attempt to restore these projects as the mentioned hack doesn't work inside Visual Studio. FWIW, generating such NuGet.config file and placing it next to solution files when required is currently handled by slngen.proj:

runtime/src/libraries/slngen.proj

Line 33 in c156ebe

<Target Name="AddNuGetConfigToSolution"

I propose that we remove all "TargetFrameworkSuffixes" / TargetPlatforms / RIDs (whatever you would like to call them) from .NETFramework tfms and let the packaging targets handle the cases where a RID specific asset is required in the package. As NuGet will likely never support RID specific .NETFramework tfm aliases, the distinction between a RID specific and a RID agnostic .NETFramework tfm is unnecessary.

cc @joperezr @ericstj

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Libraries which target .NET Framework usually have rid agnostic tfms, i.e. net461. If the library targets netstandard2.0-windows as well, the .NET Framework tfm must be rid specific, as rid specific .NET Framework apps would otherwise pick the .NETStandard asset over the .NETFramework one (based on the RID compatibility rules). There is yet another reason that requires .NETFramework tfms to be RID specific, which is when a project P2Ps other projects which are rid-specific. Without the RID specific .NETFramework tfm, a compatible .NETStandard asset would be picked instead.

NuGet doesn't support setting a TargetPlatform in the TargetFramework alias when targeting .NETFramework or .NETStandard. Any such tfms in dotnet/runtime are currently leveraging a hack that strips the TargetPlatform / TargetFrameworkSuffix away during restore and packaging (as NuGet Pack uses the project.assets.json file). For any project that includes a RID specific .NETFramework or .NETStandard tfm, a NuGet.config file must be present next to the solution file so that Visual Studio doesn't attempt to restore these projects as the mentioned hack doesn't work inside Visual Studio. FWIW, generating such NuGet.config file and placing it next to solution files when required is currently handled by slngen.proj:

runtime/src/libraries/slngen.proj

Line 33 in c156ebe

<Target Name="AddNuGetConfigToSolution"

.

I propose that we remove all "TargetFrameworkSuffixes" / TargetPlatforms / RIDs (whatever you would like to call them) from .NETFramework tfms and let the packaging targets handle the cases where a RID specific asset is required in the package. As NuGet will likely never support RID specific .NETFramework tfm aliases, the distinction between a RID specific and a RID agnostic .NETFramework tfm is unnecessary.

cc @joperezr @ericstj

Author:	ViktorHofer
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

[ericstj]

I propose that we remove all "TargetFrameworkSuffixes" / TargetPlatforms / RIDs (whatever you would like to call them) from .NETFramework tfms and let the packaging targets handle the cases where a RID specific asset is required in the package

Agreed.

Would we have some place that would catch if we got things wrong? I imagine "getting it wrong" would look like exposing a type def where we needed a forward.

I think if we told the SDK to raise runtime targets for .NETFramework then package testing would likely catch this. Not sure if PackageValidation would catch it, though that could be something to look into as well.

[ViktorHofer]

Would we have some place that would catch if we got things wrong? I imagine "getting it wrong" would look like exposing a type def where we needed a forward.

EDIT: Protection is a good idea to prevent this from regressing in the future.