[Steamworks.NET] Could not load [lib]steam_api.dll/so/dylib

[local306]

Currently running Unity 2019.3.6f1 on Windows 10. 32 bit deployment target. Mono backend. Steamworks.NET release 14.0.0.

Relates to: #349, #287, #53, and some others floating about.

My Project was fine and working well with Steamworks.NET without any issue until this last update build of mine which caused me the following upon launching in Steam (as per my log):

Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/steam_api Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/steam_api.dll Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/steam_api Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/libsteam_api Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/libsteam_api.dll Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/libsteam_api Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/steam_api Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/steam_api.dll Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/steam_api Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/libsteam_api Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/libsteam_api.dll Fallback handler could not load library <Drive>:/Steam/steamapps/common/<GameName>_Data/Mono/libsteam_api [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_api at (wrapper managed-to-native) Steamworks.NativeMethods.SteamAPI_RestartAppIfNecessary(Steamworks.AppId_t) at Steamworks.SteamAPI.RestartAppIfNecessary (Steamworks.AppId_t unOwnAppID) [0x00005] in <64280c0382684abcb0367fc40ba34fcf>:0 at SteamManager.Awake () [0x0006b] in <77a830eec29b452880338dc5813d1fcf>:0 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

Nothing changed from within the Steamworks.NET content I've been using.

Within my project, I have added in some packages and noticed now that my <GameName>_Data/Plugins folder has a x86 directory (I think the Burst package adds this to build given the libraries within it).

When I move my steam_api.dll into the x86 directory, I have been able to launch my game via Steam once again. Hasn't seem to be an issue when running either now.

Is there something hardcoded somewhere that doesn't allow it to see the first steam_api.dll outside of the x86 directory?

[wagenheimer]

I have the same problem with Mac OS on Unity 2020.3.4.
On Build Console I found this
"Deleting 'C:\Games\Green Sauce Games\Storm Tale 2\Temp\StagingArea\Storm Tale 2.app\Contents\PlugIns\libsteam_api.so' because it cannot be signed.
System.Threading._ThreadPoolWaitCallback:PerformWaitCallback ()"

With no callstack so I don't know WHO is deleting the file.

[wagenheimer]

I also find out that steam_api.bundle is not being copied to the destination folder anymore.

[rlabrecque]

This should be fixed as of #414. Now that we ship .meta files libsteam_api.so should no longer be copied on macOS and steam_api.bundle should have the correct CPU settings.