The code used to do the cornerstone of work - changing method code at runtime - was extracted from Hamonyproject and is located in scripts/Detour.cs.
It works with native x86 code and closely integrates with Mono framework.
Since then this functionality has been extracted from Harmony and developed in MonoMod.Common project. Most importantly it supports more processor architectures (actually only x86 and ARM?) and other .NET runtimes (.NET Core, 5, 6). The latter might be important in case Unity would finally move away from Mono. It also has the potential to (or does it already?) run on other platforms, such as Android. Harmony now uses MonoMod.Common.
Since then MonoMod.Common project has not quite been adopted to newer platforms. Importantly, here it says it won't support .NET 7 and Apple Silicon processors, at least in the present form, but there is some work on the required redesign as well as some alternative initiatives. Related issues from Harmony's side: https://github.com/pardeike/Harmony/issues/424, https://github.com/pardeike/Harmony/issues/504.
For this project the same tour is needed: replace the old Detour.cs file with a dedicated library, either MonoMod.Common, its successor (MonoModReorg.RuntimeDetour/), or something similar.
This should be rather straightforward re-plumbing, except that here we deture external methods, which may impose its own issues (e.g. handling of MarshalAs attribut), as opposed to regular .NET methods which are targeted by such frameworks.
From user perspective the only downside is it will likely require to bundle a 3-party DLL file, instead just a of transparent sources as it is now.
I'm marking this issue as up-for-grabs as I likely won't tackle on this (and I likely won't use Unity anymore).
The code used to do the cornerstone of work - changing method code at runtime - was extracted from Hamonyproject and is located in scripts/Detour.cs. It works with native x86 code and closely integrates with Mono framework.
Since then this functionality has been extracted from Harmony and developed in MonoMod.Common project. Most importantly it supports more processor architectures (actually only x86 and ARM?) and other .NET runtimes (.NET Core, 5, 6). The latter might be important in case Unity would finally move away from Mono. It also has the potential to (or does it already?) run on other platforms, such as Android. Harmony now uses MonoMod.Common.
Since then MonoMod.Common project has not quite been adopted to newer platforms. Importantly, here it says it won't support .NET 7 and Apple Silicon processors, at least in the present form, but there is some work on the required redesign as well as some alternative initiatives. Related issues from Harmony's side: https://github.com/pardeike/Harmony/issues/424, https://github.com/pardeike/Harmony/issues/504.
For this project the same tour is needed: replace the old Detour.cs file with a dedicated library, either MonoMod.Common, its successor (MonoModReorg.RuntimeDetour/), or something similar. This should be rather straightforward re-plumbing, except that here we deture
externalmethods, which may impose its own issues (e.g. handling ofMarshalAsattribut), as opposed to regular .NET methods which are targeted by such frameworks. From user perspective the only downside is it will likely require to bundle a 3-party DLL file, instead just a of transparent sources as it is now.I'm marking this issue as up-for-grabs as I likely won't tackle on this (and I likely won't use Unity anymore).