Updating or removing a package that includes native plugins

I'm trying to figure out what the correct, or "best", solution to this problem is.

I have a package I am developing. It includes some native C++ libraries (DLLs on Windows). The package provides some custom EditorWindows for the various utilities the package provides. In a number of cases, some or all of the native plugins are loaded as a result of some of these EditorWindows being opened, which for a user can often be "when Unity launches". So even without entering Play mode in their game, Editor scripts have referenced the plugins as potentially as early as opening the project.

Now the plugins are locked. they won't be unloaded by Unity until Unity is exited. On Windows in particular the DLLs themselves can't be deleted or overwritten while Unity is running.

So if, while the user has a Unity session running, how are they supposed to update or delete the package in the Package Manager? The common advice of "restart Unity" doesn't seem to apply because once the Editor relaunches, the DLLs are immediately loaded again. I can only think of a couple "solutions":

1. Tell the user to exit Unity, and then navigate to where the package is installed in Windows Explorer or Finder or whatever, and delete it entirely before re-opening the project in Unity. This is extremely ugly and unprofessional design. Absolute no-go.

2. Modify package code so that the plugins are not auto-loaded simply by opening the project. This is potentially workable. There would need to be some sort of "line in the sand" that's conveyed to the user as they begin using the tools, something like "once you click this button, the package can't be modified without restarting Unity!". This is quite inelegant.

And, even without my "special case" of having the plugins auto-loaded by the editor, there should still be a general solution to managing packages that use plugins. A developer deliberately managing their own plugins accepts the burden of needing to restart the editor from time to time, but a developer that's using a third party Package which uses its own plugins may not appreciate the experience, and that is potentially a lost customer. Has anyone come up with a more creative/elegant answer?

 

Hey there!

The short story of this is that native library unloading is dangerous and not supported. Restarting a process is the only way to unload a native library safely.

Plugins can be unloaded, but not safely. Unloading a native library could cause a crash or memory corruption if any native code holds pointers to types or functions in that library.

Also, having a second instance of the same library loaded is not much of an improvement, as it means you now have two contexts, so some function calls will point to the original library and some will point to the new one.

 

Yes, I understand the background technical reasons why Unity requires the user to restart the editor in order to unload a native plugin once it's been loaded.

My question has to do with incorporating native plugins in a UPM package, specifically, is there a suggested or ideal workflow for including updated plugins within a new version of a package that the user downloads while working on their project.

Even if the user of my package is a knowledgeable Unity developer and they understand how native plugins can't be unloaded, from their perspective my package's inclusion and dependency on these plugins is obfuscated (i.e. the user didn't put them in Assets, *I* put them there, and they're "hidden" (so to speak) in the Library/PackageCache folder. And so I'd like to avoid burdening the user with trying to figure out why my package appears to have not updated correctly.

So far all I can think of is just exposing to the user through alert dialogs, console log messages, and documentation, that the plugin dependencies are there, and that performing updates on the package might require an extra step or two.

 

I ran this past the team who agree that this would be the only sensible solution if you wish to include the native plugin in the package.