The first closed test of HarmonyX revealed some quirks, such as a difference in reverse patcher behavior. While almost no one was using this feature and there were known workarounds for the issue, it suggested that HarmonyX might not be a true drop-in replacement. We continued the test as a public beta to see if there were any more issues, and we did find some.

For example, we found that patching some game structures caused an AccessViolationException with no known workarounds. Since major mods depend on patching those structures, this issue is unacceptable. We therefore decided that the best course of action would be to continue using Lib.Harmony but introduce a fork that fixes some development issues that HarmonyX was fixing for us.

If you switched to the HarmonyX package, you need to switch to Bannerlord.Lib.Harmony. The version schema will be reverted to v2.2.2. We will support mods that were written and will be written with *Lib.Harmony** indefinitely. We do not force you to use Bannerlord.Lib.Harmony to develop mods, but if you do, it should ease cross-platform support for Steam/GOG/Epic and Xbox versions of the game.

Why is a fork necessary?
The original Lib.Harmony supports both game's runtimes - .NET Framework 4.7.2 and .NET Core 3.1. To build a mod, you can either target each runtime separately or use a shared target that can be used by both runtimes - netstandard2.0. However, Lib.Harmony doesn't support netstandard2.0. We fix this by reintroducing it back for modders in our fork.

Additionally, Lib.Harmony packs its dependencies differently. MonoMod.Common is included in Lib.Harmony (static linking) for .NET Framework, while on .NET (Core) it's a separate dependency (dynamic linking). With our fork, we switch to dynamic linking on both runtimes.

While HarmonyX supported these changes out of the box, we need to reinvent the wheel for Lib.Harmony with the fork.