Consider using a different assembly name and namespace from the original Harmony about harmonyx HOT 5 CLOSED

There are a few reasons why this is, mostly that HarmonyX is binary compatible with any mod that uses the original Harmony 2 when loaded in its place. The intended case here is to just outright replace the original Harmony DLL if you need HarmonyX for something, like UnityExplorer apparently does.

As for changing the assembly name, that is an obviously breaking change for anything that currently uses HarmonyX, and loading both Harmony and HarmonyX if you were to allow it would break a multitude of things in silent ways if the community at large were to begin to depend on both seperately. Communities are forced to chose one or the other because doing otherwise will break things.

It seems UnityExplorer might just be compiled against HarmonyX where it could compile against Harmony (mods compiled against HarmonyX are not binary compatible with Harmony sometimes, due to a few extra method overloads, like the Patch method UnityExplorer is looking for in that stack trace). So if you wanted to use it with the original Harmony instead of swapping for HarmonyX, you can just swap out the dependency for Harmony and recompile and it (should?) work fine.

from harmonyx.

There are a few reasons why this is, mostly that HarmonyX is binary compatible with any mod that uses the original Harmony 2 when loaded in its place.

Unfortunately that logic is flawed, as the reverse isn't true. Since HarmonyX implements features not available in the original Harmony, Harmony can't be used as a replacement. UnityExplorer make heavy use of some HarmonyX-only features like extern method patching.

from harmonyx.

Why does the reverse need to be true? In cases where it is used, HarmonyX is intended to be the replacement for Harmony, not the other way around.

from harmonyx.

Why does the reverse need to be true?

Well, in the game I'm targeting (KSP), Harmony (original fork) is the norm. Trying to make everyone update to HarmonyX instead is doable but I would rather not go that route unless there are no other options.

from harmonyx.

Greetings!

As @Windows10CE mentioned, one of the project goals is to introduce features, improve the core patching process and extend the original patching targets while maintaining compatibility with patches written for Harmony 2. As per the README, one of the features is:

Patching feature parity with Harmony while reducing code duplication using MonoMod.RuntimeDetour

More goals and differences are listed in the wiki, but one of the main ones was to maintain binary compatibility. In other words, plugins originally written for Harmony can be run with HarmonyX without recompiling. This was done because many plugins for BepInEx (the modding framework that HarmonyX was made for originally) used Harmony. We had some basic shims at some time, but maintaining them became much harder than the changes we wanted to make to Harmony. This allowed us to add features that otherwise wouldn't get PR'd into Harmony or that would get in, but we would have to wait for months for a release.

As said, the project's goal is to maintain binary compatibility from Harmony, not the other way around. We aim to maintain this approach, so this request is a wontfix. We already have had similar situations of people trying to use mixed assemblies, and in those cases, we have suggested doing one of the following:

• Switch to HarmonyX. It's specifically aimed at Unity games, is binary compatible with Harmony and has a much faster release schedule. If you have compatibility issues (e.g. something that worked in Harmony doesn't work in HarmonyX), feel free to create an issue with the specific case.
• Use Harmony. If the community already uses Harmony extensively, continue to use it. If any tools are written for HarmonyX, switching back to Harmony can require a bit of code editing (most of the features can be shimmed via MonoMod.RuntimeDetour), but overall is not an impossible task.
• Feel free to fork HarmonyX and change it to your needs/tastes. That said, we welcome PRs and try to get features into upstream Harmony as well (e.g. EmitDelegate was originally from HarmonyX but is now in upstream).

To summarise, this is a big wontfix. Even if we ignore that changing the assembly name and namespaces is a breaking change, it will go against our goal for binary compatibility with Harmony API. I'll close this issue as such, but feel free to continue the conversation.

from harmonyx.