Add NetCoreAppCurrent rid agnostic tfm to libs #64518
Conversation
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsThis change adds a NetCoreAppCurrent rid-less configuration which throws
These are the only libraries that were missing a RID agnostic tfm. Adding rid-less configurations, even if they just throw PNSEs helps with:
Even though the added tfms add to the build, I have other changes
|
ViktorHofer
force-pushed
the
NetCoreAppLibAgnosticTfm
branch
2 times, most recently
from
cf9b401
to
0d38246
Compare
This change adds a NetCoreAppCurrent rid-less configuration which throws a PNSE to the following libraries: - System.Console - System.IO.Compression.ZipFile - System.IO.Compression - System.IO.FileSystem.DriveInfo - System.IO.MemoryMappedFiles - System.Net.Http - System.Net.Mail - System.Net.NameResolution - System.Net.Primitives - System.Net.Requests - System.Net.WebSockets System.Private.Runtime.InteropServices.JavaScript is excluded from that list as it doesn't have a contract and hence can't generate a PNSE assembly. Also it's currently a private assembly. These are the only libraries that were missing a RID agnostic tfm. Adding rid-less configurations, even if they just throw PNSEs helps with: - Platform enablement, i.e. a new "base" platforms like "Browser" usually require libraries that are RID specific to support them. By offering a RID agnostic PNSE tfm, projects can gradually support new platforms. - Making it possible to have ProjectReferences between libraries, i.e. imagine an microsoft.build.notargets / microsoft.build.traversal project with a `$(NetCoreAppCurrent)-$(TargetOS)` tfm which P2Ps all source projects. NuGet can't know that a $(NetCoreAppCurrent)-Linux tfm can reference a project with a $(NetCoreAppCurrent)-Unix tfm and will throw during restore, more precisely during the compatibility check. Ideally NuGet or the SDK would support targeting platforms from the runtime.json RID graph, including its compatiblity matrix but that isn't the case today. Even though the added tfms add to the build, I have other changes in the pipeline which depend on this one which will make the build noticeably faster.
ViktorHofer
force-pushed
the
NetCoreAppLibAgnosticTfm
branch
from
0d38246
to
75281ee
Compare
...time.InteropServices.JavaScript/src/System.Private.Runtime.InteropServices.JavaScript.csproj
Show resolved
Hide resolved
src/libraries/System.IO.Compression.ZipFile/src/System.IO.Compression.ZipFile.csproj
Outdated
Show resolved
Hide resolved
src/libraries/System.IO.FileSystem.DriveInfo/src/System.IO.FileSystem.DriveInfo.csproj
Outdated
Show resolved
Hide resolved
|
I looked through the other eight libraries and they don't seem to have a suitable platform agnostic configuration already. Please let me know if you have any other feedback and if not, let's get this in :) |
|
FYI @dotnet/area-system-io @dotnet/ncl @dotnet/area-system-console |
| @@ -31,21 +31,29 @@ | |||
| <PropertyGroup> | |||
| <ILLinkDirectory>$(MSBuildThisFileDirectory)ILLink\</ILLinkDirectory> | |||
| </PropertyGroup> | |||
| <!-- DesignTimeBuild requires all the TargetFramework Derived Properties to not be present in the first property group. --> | |||
| <PropertyGroup> | |||
| <TargetPlatformIdentifier>$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)'))</TargetPlatformIdentifier> | |||
There was a problem hiding this comment.
Can we or is it worth to this globally for all projects that multitarget or is that an expensive call? I ask cause I see this property being set in multiple projects.
I guess it won't work because of DesignTimeBuild but I figured I'd ask.
There was a problem hiding this comment.
The SDK already does this but in the TargetFrameworkInference.targets file which means the property won't be for properties inside the project file. Because of that, we are setting it ourselves in exactly the same way the SDK sets it and the result will be cached and the duplicate is avoided.
We can't set this globally as it relies on the TargetFramework prop which isn't available at that point.
ghost
locked as resolved and limited conversation to collaborators
This change adds a NetCoreAppCurrent rid-less configuration which throws
a PNSE to the following libraries:
System.Private.Runtime.InteropServices.JavaScript is excluded from that
list as it doesn't have a contract and hence can't generate a PNSE
assembly. Also it's currently a private assembly.
These are the only libraries that were missing a RID agnostic tfm.
Adding rid-less configurations, even if they just throw PNSEs helps with:
require libraries that are RID specific to support them. By offering a
RID agnostic PNSE tfm, projects can gradually support new platforms.
imagine an microsoft.build.notargets / microsoft.build.traversal
project with a
$(NetCoreAppCurrent)-$(TargetOS)tfm which P2Ps allsource projects. NuGet can't know that a $(NetCoreAppCurrent)-Linux
tfm can reference a project with a $(NetCoreAppCurrent)-Unix tfm and
will throw during restore, more precisely during the compatibility
check. Ideally NuGet or the SDK would support targeting platforms from
the runtime.json RID graph, including its compatiblity matrix but
that isn't the case today.
Even though the added tfms add to the build, I have other changes
in the pipeline which depend on this one which will make the build
noticeably faster.