-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User Story: Package authors can multi-target between runtime identifiers (RID) #5699
Comments
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: |
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. |
@aortiz-msft thoughts? |
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: 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 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 Since there is no linux-specific TFM, I cannot multitarget a project in the usual way now. See also dotnet/sdk#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. |
Please reopen this @terrajobst @mairaw @marcpopMSFT @baronfel |
@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. |
Spec TBD
The text was updated successfully, but these errors were encountered: