I’m writing a C++ DLL, but it’s project type in VS 2017 is “Windows Universal DLL”. When I build and compile this DLL for x64, and drag it into the Unity Plugins/X86_64 directory, it shows up fine, and I see the plugin inspector show “Any Platform” is checked, and (with the project type being UWP), I see SDK = “Any SDK”, and CPU = “x64”, and ScriptingBackend = “any”. The DLL information says the path and “type = native”.
When I try and load the dll with the dllimport line, it says “Failed to load Assets/Plugins/x86_64/PluginUWP1.dll”, with error “The specified module could not be found”.
#1: this IS a debug dll #2: it was built with VS 2017, with v141 toolset #3: doesn’t include anything else, it’s basically a blank(ish) dll. no dependencies. #4: dependency walker says the only thing it really depends on is vcruntime140D.dll
Any clues? My DLL pretty much has to be a UWP-flavored dll. I’m thinking it’s a manifest issue, or a signing issue, or that Unity just can’t load UWP dlls?
unity’s plugin example, the one I found, is really incomplete. I wish you guys had a better one…
which configuration are you building the generated VS project in? This could be caused by mixed Debug and Release C runtime versions. When you build the generated VS project in Debug, it will deploy Debug C Runtime with your application, which is compatible with DLLs built in both Debug and Delease. However, if you build it in Release or Master, it will deploy Release C Runtime with your application, which is not compatible with DLLs built in Debug configuration (and your DLL linking to vcruntime140D.dll indicates that you built your DLL in Debug).
If that is not what’s causing it, you’ll need to look at loader snaps to figure out why the DLL fails to load:
Pop open command prompt, navigate to “C:\Program Files (x86)\Windows Kits\10\Debuggers\x64” and execute this command line to enable loader snaps for your process:
gflags.exe -i "<your_exe_name>" +sls
For instance:
gflags.exe -i "New Unity Project 45.exe" +sls
Launch your game through Visual Studio and play it until your DLL fails to load.
Look at the Visual Studio output window - it will contain a verbose log of Windows DLL loader for your process. Look for your DLL name - it should say why it failed to load.
In the command prompt, execute this command to disable loader snaps for your process:
Oh, the UWP DLL can’t be loaded in the editor? I have no idea whether you can load a UWP DLL in win32 process tbh. But using loader snaps should work for the editor too (replace <your_exe_name> with Unity.exe) if you attach VS debugger to it.
well, a normal x64 dll works, but the UWP native C++ x64 dll does not. who knows what I’m talking about? My version of unity is the x64 version, not x86.
I don’t think it is a Unity bug, Mono just calls LoadLibrary on your DLL and that fails, apparently (probably due to missing dependencies or incompatible linker flags). If you strongly believe it is our bug, feel free to report it through our bug reporter and we’ll look into it eventually.
well, honestly, I didn’t know there even was such a thing as a UWP C++ DLL before last week. I figured ANY DLL loaded into a UWP program’s space also became UWP by the fact it had been loaded. And perhaps this is true, and is also why my UWP DLL is failing whereas the normal DLL is loading. I have no idea until I put a lot more time into this issue. I was more hoping somebody at Unity had tried writing a UWP native DLL and tried loading it as a plugin and said, “whoops, you can’t do this”, and somebody would tell me so. Until that happens, it’s still a mystery on my end. I’ll let you guys know what I find out. (I work closely with your development team in my job @ Microsoft)
@Tautvydas-Zilys thank you for your help in this thread. I am in an identical situation to the original poster. I have a C++ debug x64 UWP DLL, “NowSoundLib.dll”, built from this library. I am trying to load it from a Unity debug x64 UWP app. I have copied the NowSoundLib.dll file everywhere – into my Unity UWP app’s bin\x64\Debug directory, the bin\x64\Debug\Core directory, the Plugins and Plugins\x64 directories. I continue to get nothing but DllNotFoundException when trying to call a DllImport method on it.
Running Unity 2017.4.0f1 personal.
I tried taking your good gflags.exe advice. I’ve used gflags.exe on Win32 executables in the past, no problem. Unfortunately, when I try to use it on the UWP .exe of my app here, it seems to have no effect whatsoever. My app’s name is “Holofunk-Unity” – I see a bin\x64\Debug\Holofunk-Unity.exe executable, and a bin\x64\Debug\Core\Holofunk-Unity.exe executable, but using gflags to set “Show loader snaps” on both of those has no effect. Not even setting “Show loader snaps” in the “System Registry” tab of gflags.exe has any effect. The VS2017 debug output does not change at all; no additional detail is actually provided.
Thanks very much.
Edit: Following various further links I used Application.dataPath to discover that my app was actually in bin/x64/Debug/AppX. Turns out copying my DLL to that location fixes the DllNotFoundException. @BroncoBilli you may want to try this. I now get an EntryPointNotFoundException but hopefully that will be easier to deal with And this probably explained my gflags.exe trouble.
(Why does Unity drop four different executables under bin/x64/Debug when compiling for UWP? Kinda confusing )
@RobJellinghaus Did you drop that DLL into your Unity Project? If it’s configured to be compatible with UWP in the plugin inspector, Unity should automatically setup the Visual Studio project to copy your DLL into AppX folder of the app.
As for GFlags.exe not giving you any output - any chance your debugger is configured to debug “managed only” code? I believe loader snaps output dumps into native debugger console, so you’ll have to set your debugger be “native only” or “mixed”.
Lastly, bin/x64/Debug folder is populated by Visual Studio, so it’s not us that’s dumping stuff there :).
@RobJellinghaus : sounds to me like you’re trying to build/compile/debug. I can see that the DLL should be in /bin/x64/Debug/AppX if that were the case. I am trying to RUN the unity project FROM THE EDITOR. Honestly, at this point, I could care less if I can compile it and THEN run it, if I can’t iteratively make changes and run it from the editor, what’s the point? So, Tautvydas/whoever - no, dropping the dll right onto the Unity project, if it’s a UWP-based DLL, doesn’t work. If I drop a non-UWP DLL onto the project, it DOES work. Still waiting for an answer…
clarification: I am trying to debug right from the unity project. Not by compiling it first. Can somebody at Unity create a UWP C++ DLL, give it 1 method, then try to access that DLL from Unity? It took me about 5 minutes to try this, can somebody at Unity try?
Why would you even do that? Would you expect iPhone native plugins to work in the editor? Editor runs as Windows desktop application, so your plugin should be compiled for that when running in the editor.
Yeah, that doesn’t work. But neither does it work when trying to load that into an empty win32 console application.
Why would I even do that? Because I was under the impression that the Unity Editor (main program) was a desktop app, but when you press play and start debugging, it silently fires up a UWP app, sends it the code, and tells it to run. Sure, Editor runs as a Windows Desktop app, but why wouldn’t the runtime engine that I’m debugging, the thing that is running my game, why wouldn’t that be a UWP app, if I’ve selected UWP as my platform type? I don’t see it documented anywhere that when I’m debugging and pressing play that the thing I’m debugging is STILL a desktop app! (show me where?)
If this is true, that the engine I’m debugging and stepping through is desktop-based, then yeah no kidding it can’t load a UWP C++ DLL. But I don’t see this documented anywhere.
I’m not Unity, but I can tell you from past experience that this is exactly right: when you run a game within the editor, it is not even a separate process — it runs right within the same process as the editor itself. This is why, for example, when you stop your game at a breakpoint with a debugger, the whole Unity IDE is halted as well.
When you press play, editor runs your code in the same process, which is a desktop application. There’s no hidden UWP app anywhere. I don’t know where you got an idea that there was, since there’s no documentation that says this is a thing.
And this probably explained my gflags.exe trouble.
)