Cannot load Steamworks.NET on Silicon Mac since release 2025.161.0

[Chaosed0]

Since release 2025.161.0, I get an error like this when trying to load Steamworks.NET.dll on a Silicon M1 Mac:

Could not load file or assembly 'Steamworks.NET, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The assembly architecture is not compatible with the current process architecture.

This occurs any time I try to call a method that uses Steamworks.NET. I assume it is related to this issue, but I'm failing to see how it could have made things worse.

I tried both the release version and a custom build (cross-compiled from Windows). I also get the same error using release 2025.162.1.

We were previously using a custom-built version from commit 4a54dc77a (slightly before Release 2024.8.0), and weren't having any issues.

[chandlerpl]

Hello, are you using Unity or an engine like Godot built on the newer .NET runtime?

if you're not using Unity then it would seem the release version does not have an OSX-Linux-arm64 build in, but you should be able to custom build it as long as you correctly set the Build Configuration, it seems the OSX-Linux|arm64 config is missing from the solution so you may need to manually select it, I have created a PR that adds it into the options for future releases.

Also, to answer the question you left on the other thread, the different between Steamworks.NET.csproj and Steamworks.NET.Standard.csproj is the target framework, Standard is built against netstandard2.0 which allows it to work with the newer .NET runtime, while the other version is built on .NET Framework 4.8 which is what Unity uses, and is more Windows-only (not strictly, but it never had built-in support for Arm).

[Chaosed0]

We're on Godot. Thanks for the advice, managed to get it working - I ended up compiling a portable version of the DLL targeting Any CPU. I feel that might be the right way to go for official releases, as it would be quite inconvenient to have to dynamically load the correct DLL based on the current processor architecture I'm targeting.

[Akarinnnnn]

TBH Unity users is not recommended to reference DLLs, use UPM link provided in README.md instead. UPM link is designed for Unity natively, only it can handle A lot of Unity specific problems.

Steamworks.NET.Standard and .AnyCPU is designed for regular NuGet consumption rather than direct DLL reference. It means .NET SDK is responsible to help you reference proper Steamworks.NET DLL and copy its corresponding steam library to correct place,

[Akarinnnnn]

if you're not using Unity then it would seem the release version does not have an OSX-Linux-arm64 build in, but you should be able to custom build it as long as you correctly set the Build Configuration, it seems the OSX-Linux|arm64 config is missing from the solution so you may need to manually select it, I have created a PR that adds it into the options for future releases.

This is correct, the Steamworks.NET package is third party and a bit outdated, which targeting to a steam API that does not contains arm64 support. You can follow the instructions in Standalone2.0 folder to build your own package with osx-arm64 support. Hope this will help to you. By the way, the osx-arm64 is there for a year, but before @chandlerpl create his PR to display it in VS, it is hidden for almost one year without being noticed. Thank you for completing this.