Simplify .NETFramework tfms by avoiding the "-windows" RID #58495
Comments
dotnet-issue-labeler
bot
added
area-Infrastructure-libraries
untriaged
|
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsLibraries which target .NET Framework usually have rid agnostic tfms, i.e. NuGet doesn't support setting a runtime/src/libraries/slngen.proj Line 33 in c156ebe 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.
|
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. |
EDIT: Protection is a good idea to prevent this from regressing in the future. |
ghost
added
the
in-pr
ViktorHofer
removed
the
untriaged
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). 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. 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. Explictly don't set TargetsWindows to true for .NETFramework builds as the Targets* properties are infered from the platform / suffix and many projects make the assumption that net461 (without the "-windows" part) doesn't set TargetsWindows=true. Fixes dotnet#58495
* Simplfy .NETFramework tfms 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). 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. 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. Explictly don't set TargetsWindows to true for .NETFramework builds as the Targets* properties are infered from the platform / suffix and many projects make the assumption that net461 (without the "-windows" part) doesn't set TargetsWindows=true. Fixes #58495 * Warn on .NETFramework duplicate runtime assets * Ignore .NEtFramework non Windows and non empty RIDs Also cleaning up the packaging.targets file and removing the ExcludeFromPackage option which isn't needed anymore as target frameworks aren't excluded from packages produced in dotnet/runtime anymore.
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Libraries which target .NET Framework usually have rid agnostic tfms, i.e.
net461. If the library targetsnetstandard2.0-windowsas 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
TargetPlatformin 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
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
The text was updated successfully, but these errors were encountered: