RuntimeCompiledCPlusPlus has it's own mechanics to compile cpp file into object file, which in a turn leads to need of linking .cpp into .dll. This means that native C++ can be supported, but most probably managed C++ is out of question.

It would simplify hot reload support if .dll could be just reloaded as such, and compile and linking would be handled by visual studio IDE / build chain.

To support .dll re-loading - maybe it makes sense to load entire .dll into RAM so file lock would not be present and IDE can compile .dll out of box.

Loading .dll into RAM is something that is supported with some limitations by C#, but not native C++ - until now -

https://github.com/tapika/dllloader

This project demoes how dll can be loaded into RAM for windows. (Somehow similar approaches can be found for other os's - for example https://x-c3ll.github.io/posts/fileless-memfd_create/)

Maybe logic of hot reload could be recoded as:

• Load .dll into ram.
• Wait for .dll to change on file system
• Check that there is no ongoing build processes (presence of msbuild, devenv.com, cl.exe, link.exe, cmake is detected) - and reload .dll

This most probably will work with native C++, with C++/cli support is also possible to achieve, but need to re-consider assembly strong naming.

I'm willing to help if anyone wants to try out this approach.