issue with built game ?

[GerardPerche]

Hi, I'm testing Unity Native Tool with the Unity editor, it works perfectly well, congrats ! But: with the built game: I attach the visual studio debugger to my game .exe: my breakpoints are never reached. (and the current project is the one for my .dll ) (please note: I manage to attach the debugger to the editor. it only does not work with the built game) Is there something I'm missing? thanks

[mcpiroman]

By default the onlyInEditor option is checked, so in built game this tool does not run and so Unity uses the regular P/Invoke, which means it loads the DLLs without __ prefix. I guess that's the issue you're facing.

If so, you can either try to attach to the 'real' DLL or uncheck the onlyInEditor option which will cause the behavior in build to match editor. I guess the latter should be more convenient.

[GerardPerche]

Thanks a lot for your reply! well.... I already tried to uncheck "only in editor" :-/

[mcpiroman]

Then it should really work. I checked it briefly myself and 'it works on my machine'. May I know closer your setup? Also, which version are you using? Is it from git/upm or .unitypackage from releases?

[GerardPerche]

• I imported the unitypackage
• my Unity version is 2019.3.13f1

My DllManipulatorScript options: All native functions: checked Only executing assembly : checked Only in editor : unchecked DLL path pattern: {assets}/Plugins/__{name}.dll Dll Loading mode: Lazy thread safe : unchecked Crash logs : unchecked

Other information: my visual studio project builds a dll named __UNP2.dll, that I copied in Assets/Plugins

thanks for your help

[GerardPerche]

Oh wait.. I rebuilt with the "development build" option activated, and I get this error in the in game console: It says: "Could not load DLL "UNP2" at path "C:/Users/xx/xx/Build/xxxx/Plugins/__UNP2.dll".

[mcpiroman]

That's interesting. Is there such a file at the given path? Unity should copy dlls from assets/plugins (and alike) to the build path. If it does not, then even the vanilla version wouldn't work. Could you verify that it works if you disable this tool? You should also rename/make a copy of your plugin without __ at so it is picked up by Unity.

[GerardPerche]

the dll is not in this folder. it's in "\x86_64" subfolder for the build game.

[GerardPerche]

OK, I managed to make it work. I copied my dll and your one (lib_burst_generated.dll) in the upper folder ("Plugins") and now I'm able to attach my debugger.

[GerardPerche]

I think the issue is that unity copies the .dll in "Plugins\x86_64" folder during build. whereas the executable tries to load them from the "Plugins" folder.

[mcpiroman]

Yeah but that isn't how it used to work. When I do build Unity doesn't make a x86_64 folder, it copies the dlls straight away into Plugins. I'll try to upgrade to your version and check if that has changed.

[GerardPerche]

I have some other projects under 2018.3: Apparently, dll are copied directly into "Plugins" folder. Maybe it's something new and 2019 specific.

[mcpiroman]

I checked this with 2019.31f1 which differs only in minor version from yours, and so in theory they shouldn't make such a change, I guess. I'll see.

[GerardPerche]

one thing: in my build settings: "for Architecture", I chose x86_64 , and not the default x_86

[GerardPerche]

for the moment, I'm going to add a .bat file to copy .dlls in the right folder. it should work :-) Thanks for your help !! :-)

[mcpiroman]

Yup, I confirm that Unity changed behavior in recent version and now DLLs are copied into architecture-specific subfolders.

Ideally, developers should place they plugins in architecture-specific subfolders too, so in your case you could/should use assets/plugins/x86_64 instead of assets/plugins. You could then set the DLL path pattern option to {assets}/Plugins/x86_64/__{name}.dll and that would work seamlessly, even in build. So technically that's not a bug or something I can mitigate in this project. I assume the best I can do about that is to mention that in readme.

[GerardPerche]

Thanks for your help :-)