Steamworks.Net and Adding Native References to 3.8 Projects

[BitBull]

Hi,

I am trying to migrate to 3.8 (new project) and am running into a runtime error DllNotFoundException ‘Unable to load ‘steam_api’ or one of its dependencies.’

I suspect that this is because the libsteam_api native reference that Steamworks.Net requires has not been included in my project but i can’t for the life of me figure out how to add a native reference to this project. The option just isn’t there.

Can anyone help? Is it because the new MacOS templates target .Net Core?

cheers

[persn]

Did you consult the documentation? http://steamworks.github.io/installation/#non-unity-instructions

[Gronk]

I know nothing about the api but this is some of the problems i encounterd moving over to 3.8 one of witch is a DllNotFoundExeption maybe it will help.

Some pointers migrating from 3.7 to 3.8 references and shared projects multiple platforms

Well this is a list of problems i have encountered and how i solved them. Maybe all of this is obvious but it might help someone staring out. If nothing else i documented this for me. Feel free to criticise, banter or mock my solutions Problem: Visual Studio 2019 likes to report nuget warnings. Yellow triangles on the monogame packages. At best everything works fine and at worst your autocomplete stops working or you cant build your project. It gets alot worse with shared pro…

[BitBull]

Thanks for the replies. Yes, I’ve consulted the docs (I have this working fine in 3.6).

The issue is not that the dll isn’t found but that the .dylib the .dll depends on is not there. It’s a runtime error rather than a build error.

After fiddling around a bit I have tried copying it manually to the same location as other .dylib files and, somewhat to my surprise, this works! I can’t find a way to add the .dylib to the project though as there is no ‘add native reference’ option as there is in my 3.6 project.

There’s probably another way to just get it to copy the file at build time so I’ll look into that.

[persn]

The traditional way of resolving native dependencies in Mono is dllmap, but I don’t know about .net core. Maybe this will help you, if not just google “dllmap .net core” and hopefuly you’ll find something meaningful https://github.com/dotnet/runtime/blob/master/docs/design/features/dllmap.md

[BitBull]

OK, so this works.

1. Create a folder structure in your project that mirrors that of the runtimes folder in the output directory, i.e…

runtimes/osx/native

2. Add the libsteam_api.dylib to your project at runtimes.osx/native/libsteam_api.dylib. It can be a linked reference, doesn’t matter, as long as the folder structure within your project is correct.

3. Open your .csproj file with a text editor and search for libsteam_api. There should be a reference to it something like this…

<ItemGroup>
    <None Include="..\Steamworks.NET\OSX-Linux-x64\steam_api.bundle\Contents\MacOS\libsteam_api.dylib">
      <Link>runtimes\osx\native\libsteam_api.dylib</Link>
    </None>
</ItemGroup>

Add a <CopyToOutputDirectory> attribute to this as follows…

  <ItemGroup>
    <None Include="..\Steamworks.NET\OSX-Linux-x64\steam_api.bundle\Contents\MacOS\libsteam_api.dylib">
      <Link>runtimes\osx\native\libsteam_api.dylib</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>

This should copy the native library to the correct place. I haven’t tried with the other supported CPDA platforms but I’m guessing that following that same procedure but using the appropriate source file and destination location for each platform should work.

[jonathanmcc]

Thanks for this.
I have been struggling with upgrading my Steam game to 3.8.

I tried something called Facepunch which simplifies the Steam interface for C# but could not get it to work.

On reading the above I reverted back to the Steamworks.NET nuget package and its all working now for Windows (have not tried OSX/Linux).

Here is what I did:

1. added Steamworks.NET.Standard.Windows.x64 nuget to the solution.
2. added steam_api64.dll to the project and set it to “Copy If newer”.
   This copies it to the target folder when building.

I will need to follow your steps above to get it to work with OSX/Linux.

[MrValentine]

Is this solved?

[BitBull]

Kind of.

The solution above works when running from Visual Studio. However, I have since discovered that that folder structure doesn’t work if you publish as a self contained app using dotnet publish. In this instance it does work if you put the .dylib at the root level along with all the other .dlls. Unfortunately this has the downside that your cross-platform project is no longer cross platform as there can only be one .dylib with that name at the root level.

So, partially solved but I don’t yet have a solution that will work when publishing cross-platform from the same project.

So