.NET Studio Integration ERR_HEADER_MISMATCH

I’m trying to get the Studio API working with a barebones Raylib project I’ve created on Mac OS. I was able to get the Core API working and playing sounds after a bit of fiddling around with the dylibs pulled from the API download. I was originally getting an ERR_HEADER_MISMATCH when creating the FMOD system but was able to resolve that by changing the name of the dylib from libfmod to fmod to match the filename used by the DLLImport atrribute. When I went to integrate the Studio API I basically got the same issue but changing the name here didn’t resolve it. I’m new to working with with unmanaged code in this way so maybe I’m missing something obvious, but any help would be appreciated. Do the dylib files need to be copied in to bin or am I missing some setup in the csproj?

That’s definitely a little strange - what versions of the Core and Studio API libraries are you using?

I was able to resolve this by redownloading 2.02 and using those includes and dylibs instead. I tried copying the dylibs into the net8.0/runtimes/osx-arm64 directory in bin and that allowed me to keep the dllimports as they originally were. What’s the recommended way of getting those there instead of copying them by hand?

Seem to be getting a second issue that I really can’t figure out after trying to clean this up little bit. When running the project the first call to the library gets a “System.DllNotFoundException: Unable to load shared library ‘fmodstudio’ or one of its dependencies”. Then dlopen(/bin/Debug/net8.0/runtimes/osx/native/fmodstudio.dylib, 0x0001): tried: ‘//bin/Debug/net8.0/runtimes/osx/native/fmodstudio.dylib’ (no such file). I made sure that both libfmodstudio.dylib and libfmod.dylib are both in that folder so I cant figure out why that would be failing. I’ve tried putting them in usr/local/lib and a couple other global locations and they couldnt be found there either.

Thanks for your patience. Based on what you’ve described, it seems like everything is set up correctly. The only thing that comes to mind is that the dylibs are getting tagged with the com.apple.quarantine extended attribute, which will cause the OS to ignore them until the attribute is cleared. Usually this presents as the OS asking for verification or saying that the file is damaged when you attempt to open it.

I’d recommend trying to manually remove the attribute via terminal with the following command to see whether that resolves the issue for you:

 xattr -d com.apple.quarantine /path/to/file