MeateaW

Yep; at one stage in my development I had 2 different files one for the 64bit library and one for the 32 bit library and then a "shim" that would pick which library to call depending on the operating system. As soon as I started thinking about mac-os support I realised it started to balloon out, instead of a simple "if 64bit" shim, I needed to add in functions to detect operating system. And I hadn't even considered the Linux OS at that point. It didn't help that the library I was using had on the order of 200 exported functions that I was trying to import. ~600 lines of code for each operating system/architecture combination just to import the files was a bit of a waste. I went down a very deep rabbit hole of DLL loading paths and functions (most of them DotNet related, not Mono) until I found some forum post about someone asking for DotNet to implement something similar to the "dllmap" feature of Mono. It was a lucky find that led me to the above solution.

Edit: @Sarbian: This post might be of interest for you also! Edit2: I just tested renaming all the files. I added .dat on the end of each filename, and did the same in the dll-map, and it works as expected. I realise you have solved all your problems but I've just recently dredged up my old modding files and got them running in the latest KSP and thought I would share something that I figured out for cross-platform external-library KSP/Unity development that might help you. (For context my mod was a variation on the various engine-balancing mods that existed back then, and still exist, ThrottleControlledAvionics [aka TCA] which still exists!) So; I learned this initially because KSP when I started modding was primarily a 32 bit application; with only a beta 64 bit branch; so I wanted to have a single list of function imports that worked for 32 and 64 bit applications; and I had a mac so I wanted to look at loading the library on that platform also. I found out about a feature that exists only in Mono, known as the "DLL Map" This allows you to use a single DLL Import, and a "Map" that maps the import to an appropriate library depending on other factors. I'll use code copy and pasted from my project: I use a library called LpSolve55, I have 32bit and 64bit modules, and modules for Windows/Mac/Linux, which gives me 6 different files I need to choose from. I do it like this: Project: LibSolver (Generates "LibSolver.dll" in my example, replace where appropriate) Create XML file: LibSolver.dll.config (MUST be the same name as the DLL that has the DLLImport commands) Mark it as BuildAction: "Content" and "Copy if Newer" (file must be sitting right next to the DLL) <?xml version="1.0" encoding="utf-8" ?> <configuration> <!-- DLL map files only work in Mono, hopefully Unity on windows (for KSP) also uses mono. --> <!-- OSX --> <dllmap dll="lpsolve55" os="osx" cpu="x86-64" wordsize="64" target="gamedata/AdvancedAvionics/x64/liblpsolve55.dylib" /> <dllmap dll="lpsolve55" os="osx" cpu="x86" wordsize="32" target="gamedata/AdvancedAvionics/x86/liblpsolve55.dylib" /> <!-- Linux --> <dllmap dll="lpsolve55" os="linux" cpu="x86-64" wordsize="64" target="gamedata/AdvancedAvionics/x64/liblpsolve55.so" /> <dllmap dll="lpsolve55" os="linux" cpu="x86" wordsize="32" target="gamedata/AdvancedAvionics/x86/liblpsolve55.so" /> <!-- Windows - Mono only potentially --> <dllmap dll="lpsolve55" os="windows" cpu="x86-64" wordsize="64" target="gamedata\AdvancedAvionics\x64\lpsolve55.dll" /> <dllmap dll="lpsolve55" os="windows" cpu="x86" wordsize="32" target="gamedata\AdvancedAvionics\x86\lpsolve55.dll" /> </configuration> The file is pretty self explanatory, depending on the architecture it loads a different file. Then for your actual DLLImport you do something like this: [DllImport("lpsolve55", SetLastError = true)] public static extern bool add_column(long lp, double[] column); Note: that the path I use for the DLLImport is the "dll" field in the dllmap file above. The actual Config file does the hard work of specifying the path to the platform-specific library. This allows you to maintain a single DllImport file, which is cross-platform. Lets you save your DLLs Libs and So's in a folder that makes sense. I haven't yet tried changing the extension on the DLLs (I'm getting your other error your other post references too) but I don't see why it won't work. Note; as mentioned in the XML config file, this is Mono specific. If Unity ever changes to run on something other than Mono (IE on Windows they use DotNet proper?) this will all fall over, and I have no idea how to fix it after that! Edit3: There is actually a side benefit from all of the above. If the basic library remains the same, but an updated version comes out, or a bug-fix and for some reason, or it relies on an operating system DLL that lives in a specific path, the dll-config file is editable by users, without needing to recompile the whole project. IE people can update files; or perhaps add their own for an architecture you don't currently have a native library for. As long as the DLL exports the same functions someone else can get a library that works; and with minimum effort supply it in addition to your existing libraries. (IE you don't list a linux library, but someone might cross-compile one for you, and adding support for it is a simple matter of updating the config file). PS. turns out I was working on this almost 4 years ago. Sigh.