Better Unity Hot Reloading?

[recatek]

I took a look at the hot reloading example in the repo, and it looks like it uses the duplicate-and-rename DLL method, which has some disadvantages. There are a few different ways of doing hot reloading in Unity, and I'd like to try using the explicit library load and GetProcAddress method instead. The main advantage of it is that you can (somewhat) easily turn it off and on using an environment variable when building, so you can switch to basic P/Invoke for shipping more formal builds. To do this, you need your function signatures to switch between [DllImport] attributes and this custom delegate syntax based on a flag, like so:

#if LATE_BINDING
    internal static
#else
    [DllImport(IMPORT_PATH)] internal static extern
#endif
    void SetShapePosition(uint shapeId, RustVec2 position)
#if LATE_BINDING
    {
        del_SetShapePosition del = Native.Library.GetDelegate<del_SetShapePosition>("SetShapePosition");
        del(shape, position);
    }
    internal delegate void del_SetShapePosition(uint shapeId shape, RustVec2 position);
#else
    ;
#endif

Is there a good way to accomplish generating these signatures with interoptopus? Maybe using a custom override (while keeping the other nice elements of the Unity override)?

[ralfbiedert]

I'd be very interested in having hot reloads, and this mechanism looks promising. Would that allow you though to actually replace the DLL on Windows since there might be a lock on the file while it's open?

[recatek]

The idea is that if you only need the DLL while the game is running, you load the DLL in play mode and close it when you exit play mode. That way you can replace it when not playing because you release the Windows lock. It's more complicated if you need the DLL in edit mode but not impossible to do either.

[ralfbiedert]

Also, does that work from regular .NET?

[recatek]

Not sure what you mean by regular .NET in this case. I believe it works for both .NET Framework and Core/Standard. It is Windows-only though because it requires using kernel32.dll for its system calls. That's why I like having the option to go back to P/Invoke for shipping builds, so you don't have that same dependency outside of the editor.

[ralfbiedert]

And have you measured the performance overhead of Native.Library.GetDelegate? And how would that fare against a mechanism where a struct of symbols is constructed and used instead?

[recatek]

That I'm not sure. I do think it's generally more reliable to use P/Invoke where possible though in shipping builds, but haven't profiled the difference.