Closed Qonfused closed 7 months ago
The current (prefix) implementation always returns a bool type and is considered a passthrough patch for postfix/finalizer:
[Diver] Hooking function MainViewModel_PropertyChanged...
[HarmonyWrapper][AddHook] Constructed binaryParams: 1100000000 for method MainViewModel_PropertyChanged
[Diver] Failed to hook func MainViewModel_PropertyChanged. Exception: System.Exception: Return type of pass through postfix Boolean UnifiedHook_1100000000(System.Reflection.MethodBase, System.Object, System.Object, System.Object) does not match type of its first parameter
This could be refactored to handle other patch positions w/ an additional return type or 'context' variable provided in the HookContext argument.
Will need to ensure callbacks are actually removed when a client terminates suddenly; can bubble up into a MagicException that may be reported erroneously:
Will be phasing out Harmony hooking, reflecting fixes with EventHandler subscription in 107872c as an immediate replacement.
Manipulating IL code to intercept (and possibly prevent or alter) methods/events can also expose inner variables or contexts not normally accessible through public MTGO APIs or COM interfaces.
Any non-primitive objects provided are still wrapped in dynamic remote objects regardless (e.g. SecureString objects are not accessible). However, these objects are not bound to their respective proxy types; this breaks the public API contract set by the object's interface and may lead to unintended or harmful client behavior.
Harmony patching may over-leverage internal implementation details and scheduling that is better implemented as part of the main API and events system.
Postfix/finalizer patches must have a return type of void or the return signature must match the type of the first parameter (passthrough mode) return types.
Refer to https://github.com/pardeike/Harmony/issues/130#issuecomment-427088993 for a simpler overview of the HarmonyLib's patching methods.