How to make packages with runtime specific managed assembly?

[Akarinnnnn]

I'm authoring package with ref & runtimes folders, using nuspec and custom MSBuild target file. When I reference that package in testing project, assemblies under runtimes folder can't be loaded at runtime. And no complication errors emitted.

Testing is executed on windows x64 runtime, so error on linux directory is not the focus, they will be fixed later. Runtime error received is FileNotFoundException. Rough translate back of the message: System can't find specified file:

The main reason the project have to build different versions for different runtimes, is our native dependency have different names on different platform("steam_api" for 32bit and "steam_api64" for 64b). Next decision make things difficult is they are imported by P/Invoke, which requires literal library name.

Considering this open source project's major consumers is Unity developer, and history burden, we can't change from P/Invoke to other importing method easily. For Unity consumers their build product is targeting to a specified runtime, everything used to determine runtime is also provided at compile time, therefore require literal library names won't cause problem.

As for PackageReference consumers, we made a SDK style project to build NuGet package. But for creating an all-in-one package contains all variant, dotnet pack didn't help. Such packages which have runtime specific assemblies have to use NuGet client and nuspec, and build variants manually.

I want to know the correct method to create packages which have runtime specific assemblies.

Below is project code and result package, nuspec generated and package directory structure is also provided.

Here is the result package produced by the instruction in project.
Result package Steamworks.NET.2025.4.23-d.nupkg.renamed.zip
And test project:
Windows x64 only Steamworks.NET.Tests.Packaged.zip

directory tree and nuspec inside the package:

│ README.md
│ Steamworks.NET.nuspec
│ [Content_Types].xml
│
├─package
│ └─services
│ └─metadata
│ └─core-properties
│ 6e920a27f406466cb37cb50606e1067e.psmdcp
│
├─ref
│ ├─net8.0
│ │ Steamworks.NET.dll
│ │
│ └─netstandard2.0
│ Steamworks.NET.dll
│
├─runtimes
│ ├─lin-x64
│ │ └─lib
│ │ ├─net8.0
│ │ │ Steamworks.NET.dll
│ │ │
│ │ └─netstandard2.0
│ │ Steamworks.NET.dll
│ │
│ ├─osx-arm64
│ │ └─lib
│ │ ├─net8.0
│ │ │ Steamworks.NET.dll
│ │ │
│ │ └─netstandard2.0
│ │ Steamworks.NET.dll
│ │
│ ├─osx-x64
│ │ └─lib
│ │ ├─net8.0
│ │ │ Steamworks.NET.dll
│ │ │
│ │ └─netstandard2.0
│ │ Steamworks.NET.dll
│ │
│ ├─win-x64
│ │ └─lib
│ │ ├─net8.0
│ │ │ Steamworks.NET.dll
│ │ │
│ │ └─netstandard2.0
│ │ Steamworks.NET.dll
│ │
│ └─win-x86
│ └─lib
│ ├─net8.0
│ │ Steamworks.NET.dll
│ │
│ └─netstandard2.0
│ Steamworks.NET.dll
│
└─_rels
.rels

nuspec file generated

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>Steamworks.NET</id>
    <version>2025.4.23-d</version>
    <authors>rileylabrecque</authors>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <license type="expression">MIT</license>
    <licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
    <readme>README.md</readme>
    <projectUrl>https://github.com/rlabrecque/Steamworks.NET</projectUrl>
    <description>Steamworks.NET</description>
    <repository type="git" url="https://github.com/rlabrecque/Steamworks.NET.git" commit="15.0.1" />
    <dependencies>
      <group targetFramework=".NETStandard2.0" />
      <group targetFramework="net8.0" />
    </dependencies>
  </metadata>
</package>

Other information:

This project first produce all assemblies by MSBuild target BatchBuild in BuildPackages.targets. In this target it will build every possible version and copy them to bin\nuget\runtime, then reference assembly and copy to bin\nuget\ref. Next I use nuspec to generate package. Please tell me if any steps contains problem.

Project code at ask point
nuspec

[Akarinnnnn]

After some investigation, I figured out that the package structure is good. Problem is in the build script: csproj. A <Platform>x86</Platform> missed in previous cleanup caused unexcepted CPU architecture mismatch. Remove it and problems are gone.