"Could not load [lib]steam_api.dll/so/dylib" on Windows. But everything is good on macOS.

[ViZAlice]

My Unity version is 6000.1.9f1. Steamworks NET version is the latest release.

A few days ago my builds was running good, i could upload the depot to steam and download game from library. I could download game and play succesfully.

But today my build turns failed when starting. Everything works good in editor and steam shows my app is running. My scripts can get the user name or something else. But i am just can not get the right result in my builds.
On windows, I can connect to steam in editor. The key of the issue is game runs good on MacOS and unity editor, but build for windows cannot run.So that I think it is not an error about my script.

Here is my unity log of the last running when start the game:

Mono path[0] = 'C:/Users/ViZA/Desktop/Builds/Bubbles_win/Bubble2_Data/Managed'
Mono config path = 'C:/Users/ViZA/Desktop/Builds/Bubbles_win/MonoBleedingEdge/etc'
Input System module state changed to: Initialized.
[Physics::Module] Initialized fallback backend.
[Physics::Module] Id: 0xdecafbad
Initialize engine version: 6000.1.9f1 (ed7b183fd33d)
[Subsystems] Discovering subsystems at path C:/Users/ViZA/Desktop/Builds/Bubbles_win/Bubble2_Data/UnitySubsystems
GfxDevice: creating device client; kGfxThreadingModeSplitJobs
Direct3D:
Version: Direct3D 12 [level 12.1]
Renderer: NVIDIA GeForce RTX 5060 Ti (ID=0x2d04)
Vendor: NVIDIA
VRAM: 3072 MB
App VRAM Budget: 15194 MB
Driver: 32.0.15.7688
Begin MonoManager ReloadAssembly
- Loaded All Assemblies, in 0.112 seconds
- Finished resetting the current domain, in 0.002 seconds
[Physics::Module] Selected backend.
[Physics::Module] Name: PhysX
[Physics::Module] Id: 0xf2b8ea05
[Physics::Module] SDK Version: 4.1.2
[Physics::Module] Integration Version: 1.0.0
[Physics::Module] Threading Mode: Multi-Threaded
<RI> Initializing input.

Using Windows.Gaming.Input
<RI> Input initialized.

<RI> Initialized touch support.

UnloadTime: 0.391000 ms
[Steamworks.NET] Could not load [lib]steam_api.dll/so/dylib. It's likely not in the correct location. Refer to the README for more details.
System.DllNotFoundException: steam_api64 assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) Steamworks.NativeMethods.SteamAPI_RestartAppIfNecessary(Steamworks.AppId_t)
at Steamworks.SteamAPI.RestartAppIfNecessary (Steamworks.AppId_t unOwnAppID) [0x00005] in <2a0c461ea54b40d293cd3d9fc23ea7d9>:0
at SteamManager.Awake () [0x00061] in <942b741b31e8478797c59396d45b5b61>:0
本地化数据读取完毕
[Physics::Module] Cleanup current backned.
[Physics::Module] Id: 0xf2b8ea05
Input System module state changed to: ShutdownInProgress.
Input System polling thread exited.
Input System module state changed to: Shutdown.
GarbageCollector disposing of ComputeBuffer. Please use ComputeBuffer.Release() or .Dispose() to manually release the buffer.

I am sure i have already put the steam_appid.txt into the game.exe folder, and the appid is right. I delete the steam_appid.txt file before upload.
Starting directly from game.exe and starting from steam library both fails.

I didn't modify the SteamManager.cs. Automatic quitting is a feature of the original script. SteamManager cannot succeed in calling the SteamAPI_RestartAppIfNecessaryso it causes my app to close automatically. This behavior is expected. The key issue is that it cannot pass SteamAPI_RestartAppIfNecessary.

[ViZAlice]

I also tested game on the other windows PC. I got the same result on my PC.

[ViZAlice]

Okay, I found the key point. Normally i can build in 32bit application on windows. Who use Inter-64bit or Inter-32bit can both run the application in compatibility. But Steamworks API didn't run in taht way.You have to build exactly bit virsion for your game.
My pc is x64. So that the Steamworks.NET will pack the steam_api64.dll to the build. But game is searching for steam_api.dll.

[rlabrecque]

Is the ability to target "AnyCPU" with Unity new? Half of why Steamworks.NET originally did not care much about trying to target both at the same time was Unity could only produce 32 or 64 bit builds, not both together.

@Akarinnnnn has an initiative started to allow AnyCPU to function, I haven't had time to look at it much though: #714

[Akarinnnnn]

Any CPU is acheived by wrappers in my work, I think it will work on Unity(even older). Why I didn't add it to Unity is because I have performance concerns. I have to say #714 has a huge size. Add a draft branch in this repo is better if we want Any CPU. I should spilt original #714 into smaller peices, then PR them to draft branch.

…

---Original--- From: "Riley ***@***.***> Date: Wed, Aug 13, 2025 04:34 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [rlabrecque/Steamworks.NET] "Could not load[lib]steam_api.dll/so/dylib" on Windows. But everything is good on macOS.(Issue #737) rlabrecque left a comment (rlabrecque/Steamworks.NET#737) Is the ability to target "AnyCPU" with Unity new? Half of why Steamworks.NET originally did not care much about trying to target both at the same time was Unity could only produce 32 or 64 bit builds, not both together. @Akarinnnnn has an initiative started to allow AnyCPU to function, I haven't had time to look at it much though: #714 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Akarinnnnn]

There are also some questionable points. Is there any changes to platform macros to Unity? If so, that change may break our platform detection, results x64 Steamworks.NET is built for x86 player. Future investigation may needed.

[ViZAlice]

Unity 支持“任意 CPU”是新功能吗？Steamworks.NET 最初不太想同时支持这两种 CPU，部分原因是 Unity 只能生成 32 位或 64 位版本，无法同时支持这两种版本。

@Akarinnnnn是否有一项计划允许 AnyCPU 运行，但我还没有时间仔细研究它：#714

Maybe here is something useful.
Unity version is 6000.1.9f1.
Here is the dll full path:
"C:\Users\ViZA\Desktop\Builds\新建文件夹\Bubble2_Data\Plugins\x86_64\steam_api64.dll"
Here is the build profile.

I don’t mean that I want to build a game for any CPU. I just thought a 32-bit app could run on a 64-bit CPU, so I built it for Intel 32-bit.
I didn’t expect that even I chose the Intel 32-bit option during the build Steamworks.NET would still export the steam_api64.dll into my build, which caused the error.
After a whole day of debugging, I finally pinpointed the problem.

(I’ve decided to drop support for 32-bit CPUs in my game. In 2025, it’s probably safe to stop worrying about 32-bit compatibility for my game.)

[ViZAlice]

I just ran some tests.
I created a profile named Steam Windows and set it to Intel 32-bit. Then I switched to another profile, such as Windows, which is set to Intel 64-bit. When I switched directly back to Steam Windows, there was no compilation, and Unity or Steamworks.NET could not correctly build to 32-bit. Somehow, it ended up partially building for 32-bit and partially for 64-bit.

How to fix it: If you set the Steam Windows CPU to 64-bit and then switch it back to 32-bit, it will trigger a proper compilation. I’m not sure whether this is an issue with Unity or Steamworks.NET.

This might be an edge case.
Though I hope the information above helps you and others who encounter the same problem.

[Akarinnnnn]

When I switched directly back to Steam Windows, there was no compilation, and Unity or Steamworks.NET could not correctly build to 32-bit. elps you and others who encounter the same problem.

Interesting, is build configuration the new feature broke us?