neos-modding-group / NeosModLoader

A mod loader for Neos VR
GNU Lesser General Public License v3.0
61 stars 22 forks source link

[Feature Request] Hot-reloading DLLs #99

Open Nytra opened 1 year ago

Nytra commented 1 year ago

This would make mod development easier because we would not need to fully close and reopen Neos every time we make a change. It could also pave the way for automatic mod updates inside of Neos.

As far as I know, the main thing stopping this is that in C# you cannot load the DLL again if it contains the same class name. A way around this could be for NML to randomize the class names somehow. This was discussed a little with @art0007i already.

Could potentially be used when launching NML in Debug mode instead of enabling it by default.

EIA485 commented 1 year ago

we have looked into this in the past and the biggest challenge is unloading the prior assembly. this was requested in our discord server in this discussion thread

its certainly something that would be nice to have, we just have to do it well while dealing with c#

not sure how we should tell the mod its being hot reloaded but #55 comes to mind with discussions on a similar topic.

something id like to look into is what bepinex does for hotreloading

Nytra commented 1 year ago

It looks like you can load a DLL into an AppDomain and then unload the AppDomain? https://stackoverflow.com/a/63729037

edit: I just realized this is what is talked about in that discussion thread

art0007i commented 1 year ago

well you don't need to unload dlls. you would just need to load the new dll and make sure to "deactivate" the old dll, I assume hot reload is specifically for development so leaking a bit of memory and writing a destructor function for your mod should be doable and still be useful.

There might also be cross mod bugs caused by this but again for a development version it should be ok.

I've already tried the double load method, and it didn't actually load the new code for some reason. the LoadAssembly function just returned the exact same assembly as the original one, even though it was a different file path and the code was also different. I didn't bother with figuring out more about why this happens. I might look through my files and see if I have that version of modloader that tried to hot "re"load (double load?) mods but like it didn't work, only because c# refused to work with me.