[BUG] Steam DLL Resolution failed on Godot Windows

[klootas]

Wow, so great to have a NuGet package for this 👏
However, I have a problem using Godot (4.7.1) that I though I might raise.

If my Godot export template has "dotnet/embed_build_outputs" unchecked, I get this output

Game.exe
data_Game_windows_x86_64/Game.dll
data_Game_windows_x86_64/steam_api64.dll

Running Game.exe result in this exception:
Unable to load DLL 'steam_api' or one of its dependencies: The specified module could not be found.
ERROR: [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.

Now... Everything works (provided I add a steam_appid.txt) if I just move steam_api64.dll up one folder, so it's next to the executable:

Game.exe
steam_api64.dll
data_Game_windows_x86_64/Game.dll

I prefer to set the Godot export template to have "dotnet/embed_build_outputs" checked (so I get just one file and no folders), but running an executable built like that predictably results in the same runtime exception as above.

Do you see hava any thoughts on this? I could programmatically move the references in a post build script, but I would have to to come up with a cross-platform way of knowing where they should be moved from. And dotnet/embed_build_outputs makes it look so neat with just one executable :)

[Akarinnnnn]

Thanks for reporting, this will be fixed in next patch.

[Akarinnnnn]

Before I actually made changes to dll resolution logic, try to change this method yourself to see will it fix your problem:

Steamworks.NET.AnyCPU/Standalone3.0/anycpu/autogen/NativeMethods.AnyCPU.cs

Line 15 in ed021dc

private static IntPtr DllImportResolver(string libraryName, System.Reflection.Assembly assembly, DllImportSearchPath? searchPath) {

This method is used to resolute steam_api[64].[dll/so/dylib]. Currently on Windows it only search for it next to Game.exe. From line 21 it might searches in directory data_Game_windows_x86_64. You can extract this branch as a fallback when steam_api is not next to Game.exe, it probablly works.

If this change works, your contribution of fix is welcomed.

[Akarinnnnn]

I have updated the title to fit this bug better.

[klootas]

Just remember that it fails even without that option set (unless I manually move the dll to sit next to the executable).

Unless you have any other ideas, I'll have a look at your suggestion tomorrow 👍

[klootas]

Ah, I think I misunderstood your reply. At first glance I thought I could just build my game with a tweaked version of your partial NativeMethods class, but I see it doesn't compile. Perhaps you ment for me to clone the repo instead?

I suspect the quickest way to a solution might be for you to try it from a Godot export yourself, to fully see the problem. This way you could also see the difference with and without the embed_build_outputs flag during export. Or if you prefer, perhaps you could do a pre-release version of the package where you allow us to programmatically add paths of where to look for the assembly? If so, I'd be happy to try it and report the results until we lock down a solution.

Thank you for looking into this, this package is really close to the perfect way to do Steam integration for any non-Unity .NET projects 👍

[klootas]

I just tried 2026.164.3, but the same issue remains:
With "Embed Build Outputs" unchecked, it still puts steam_api64.dll inside data_Darmok_windows_x86_64, so it fails when you run the executable.
With "Embed Build Outputs" checked, I don't see the steam_api64.dll at all (which may or may not be as intended).

Both options results in the same runtime exception when running the executable:
Unable to load DLL 'steam_api' or one of its dependencies: The specified module could not be found.
ERROR: [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.

[Akarinnnnn]

Need further investgation, but my Visual Studio was broken, make debugging harder before it works again. Could you reopen this issue to remind others that bug isn't fixed?

[klootas]

I do not have permission to reopen the issue, you should have though :)