Skip to content

Feature Request: Allow architecture-specific binaries without requiring client projects to use RuntimeIdentifier(s) #6846

@davidmatson

Description

@davidmatson

When to use Platforms vs PlatformTarget vs RuntimeIdentifier(s) is a bit messy at the moment. (For more context: dotnet/sdk#1553)

In the meantime, while we're waiting on guidance/cleanup there, we usually use only Platforms or PlatformTarget to mark a binary as x64.

We have NuGet packages used by these projects that have x64-only binaries in them. The only current way I can find to provide these native binaries in a NuGet package and have them show up in bin (well, apart from a custom target file) is to use the "runtimes" folder:
https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks

And have a subfolder named something like win-x64.

However, it looks like NuGet does not include these binaries in your client projects unless they also set RuntimeIdentifier(s). Perhaps this is related to the "win-" part of the architecture-specific folder. Can we provide a way to do architecture-specific folders that are not also platform-specific? Perhaps something like:

runtimes\{architecture}\native

or for example:

runtimes\x64\native\foo.dll

in addition to the existing:

runtimes\{platform}-{architecture}\native

or for example:

runtimes\win-x64\native\foo.dll

Changes on the project system/SDK side are another potential solution here, though that seems a ways off at the moment.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Priority:3Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog.Type:DCRDesign Change Request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions