Closed jamsoft closed 2 years ago
AaronRobinsonMSFT
commented
2 years ago @jamsoft Were you able to get unblock? I don't fully understand your scenario actually. DNNE does have experimental support for a self-contained deployment, but it is a manual process.
As far as AOT, if that is a path your application works with, I would AOT your plugin as well and not use DNNE at all. Dotnet's NativeAOT solution can produce a shared library or an executable binary if desired.
jamsoft
commented
2 years ago I was able to unblock. Although I've seen some oddities in the dotnet installs. At the moment for some reason, my M1 mac is missing the contents of usr/local/share/dotnet/pack/6.0.5 ... no idea how to get it installed either. That's where the host lib .a should be.
I have loads of other versions installed which is odd.
In my situation it does actually make sense to use DNNE. The library isn't referenced by my application at all and needs to be installed into a 3rd party applications user directory and loaded by that application at runtime.
I then UDP message to it from my application.
Due to the deployment scheme of .NET 6 I can't then load that dll in some random location, at least as far as I know. Also AOT prevents Assembly.Load ...
This is a really interesting project, thanks.
Although I must admit I'm a little lost. I've picked up a project that has made use of this to compile a native dll (windows at the moment). This is all working brilliantly. The native dll is a plugin for an application. When I add the plugin it's all working perfectly.
The plugin provides a way for my application to talk to the application hosting my plugin. The issue for me is I'm not clear on how to actually consume these libraries.
My application is also AOT compiled .NET6.0 application so it's naturally expecting all dependencies to be local to the main .exe but these dlls have to be in the directory structure of the host application.
Really not sure how to proceed.