0
0

I have an system which requires that the code (C#) be compiled as "Any CPU". Having two versions of the code will not work. The code must also be fully managed. I see "32-bit" and "64-bit" versions of the fmod code, but we get errors when we try to compile the 32-bit C# sources as "Any CPU". The 64-bit version appears to be C/C++ code, which is not clear that we can compile under "Any CPU" and be fully managed. Is there any way to compile fmod under "Any CPU" as fully managed code?

Thanks!

  • You must to post comments
0
0

No matter what you do, the FMOD dll is written in native code, not managed. The interfaces for C# call into the native DLL in a managed fashion, but the underlying FMOD code is native. It’s not clear if that will be a problem for your situation, but I did want to make that clear.

As for your specific issue:
When you compile a managed application in "Any CPU" mode, it will run in x86 mode on 32-bit Windows, and x64 mode in 64-bit Windows. This means that, if you reference a native DLL, you must link against code that is appropriate for whichever processor architecture you happen to be running on.

FMOD does have 32-bit and 64-bit versions which you can download, but the C# interface is only set up for 32-bit. If you look at the actual C# interface code, you’ll see that it references the FMOD DLL by filename. That is, fmodex.dll. The 64-bit version of the DLL is called fmodex64.dll.

If you wanted to compile for 64-bit, you could probably just change the referenced filename, and be done (though admittedly I have not tried this).

Your situation, though, is that you want to compile for "Any CPU", which means that the determination is made at runtime. That raises some challenges. The names of the FMOD DLLs are declared as const strings, and used when defining the function names, which means that the determination has to be made at compile time.

The conventional wisdom says "compile your managed app in x86 mode, and that’ll solve the problem," but it sounds like that’s not an option for you.

All hope is not lost, but it will involve some extra work from you. Also, it would require that you have some way of asking "am I running x86 or x64?" which I don’t know off the top of my head.

The best way I can think of to make this happen would be to make two copies of the provided fmod.cs (and, if you’re using it, fmod_event.cs). Relabel the namespace of one to FMOD64, and change which DLLs it points to. Then, create a wrapper file which routes individual functions to their respective 32-bit or 64-bit versions.

It’s a pain, but that’s the best way I can think of to make that happen, if you [i:1k6uzax4]must[/i:1k6uzax4] run in "Any CPU" mode.

Good luck! Hope that helps.

  • You must to post comments
0
0

Hi sbwong, welcome to the FMOD Forums!

Adiss is right: the fact that it is native code means you have to know whether it’s 32-bit or 64-bit. The current FMOD C# wrapper does support both 32-bit and 64-bit but does not support the "Any CPU" target. You must specifically target 32 or 64, and if you are targetting 64-bit make sure the preprocessor directive WIN64 is defined.

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.