dotnet
User Story: Package authors can multi-target between runtime identifiers (RID)
Currently multitargeting is supported via TargetFrameworks but not really for multiple RID's. In our own build, we have to do custom build gymnastics to achieve this.
The libraries team part here is representing our needs as we'd like to move over to this supported mechanism once it exists.
I think that adding a new first class concept to MSBuild, that of arbitrary build dimensions, would solve these 'we want to bolt on yet another hardcoded dimension' types of issues once and for all. A build dimension could be defined as a key value map: {foo:"bar", zoo:"roo"} {TargetFramework:"net472", RuntimeId:"win", Configuration="Debug", Architecture="x64"}. In MSBuild they could be expressed via regular items, or we could introduce new MSBuild expressions with well defined semantics. The engine could know about them to make it easier to specify multitargeting and whatnot. We could also borrow BuildXL's design of build dimensions
We should get an engineering owner assigned to this, like every P0 story, to avoid disconnects. It can always change later. It would most likely be the M1 where most of the work will happen. Is that you @marcpopMSFT or someone on your team?
My understanding is that the largest set of the work for this would be from NuGet so @aortiz-msft would probably be the M1 owner.
I think for this a decent amount of work needs to be done by MSBuild, NuGet and the SDK.
Yes, we discussed this in our Monday meeting last week, and this is not something we think we can deliver in NET 6.0. However, let's understand the customer feedback around this and start validating the problem and solution hypotheses.
As a head's up, the Extras supports this for the inner compile loop and building nuget packages: https://github.com/novotnyllc/MSBuildSdkExtras#creating-per-runtimeidentifier-packages
It doesn't likely handle P2P references in an intelligent way.
I'm looking for a way to have multitargeting for different RIDs from a single class library project - including using the RID as a compile-time condition in the .csproj to reference RID-specific dependencies, like it is possible with TFMs now. This would not only enable building the correct binaries, but it would also allow for using the correct code at compile-time using #if rather than using runtime-checks like OperatingSystem.IsLinux().
My usecase would be to create a single NuGet package (class library) that has a windows-specific and a linux-specific implementation, which could be referenced through a common API surface in a consuming head project (abstracting away the platform differences). Depending on the publishing RID of the consuming head project, the nuget package for windows or linux would be restored. By using the RID as a condition in the .csproj file, additional platform-specific dependencies could be added.
Since there is no linux-specific TFM, I cannot multitarget a project in the usual way now.
See also https://github.com/dotnet/sdk/issues/27061
@terrajobst is this still targeted for the 7.x timeframe?
CC @baronfel for visibility. This is not in plans for a 7.0 release. A feature being discussed that might help here is TFM aliasing which would allow aliases to include the RID but that isn't officially planned yet.
Bulk closing .NET 6 epics and user stories. If you think this issue was closed in error, please reopen the issue and update it accordingly.
@marcpopMSFT @baronfel @terrajobst please check if this should be reopened and if so, what release are we targeting this?
This should not be reopened as we are not planning on adding direct support for multi-targeting of RIDs. However, the nuget team is exploring TFM aliasing which would enable a form of this. The idea would be to enable the existing TFM multi-targeting to allow for RID information. It's still in design but potentially it'll end up with customers being able to multi-target "net8.0/win-x64;net8.0/win-arm64" (or something like that). We'd likely need some known aliases built into the SDK that set the RID when used but nuget would recognize those as two targets and allow restoring each separately. Customers could expand the aliasing beyond what's built in to support other scenarios we haven't thought of.
https://github.com/NuGet/Home/pull/12124