Table of Contents

Using MonoMod.Patcher

Drop MonoMod.exe, all dependencies (Utils, cecil) and your patches into the game directory. Then, in your favorite shell (cmd, bash):

MonoMod.exe Assembly.exe

MonoMod scans the directory for files named [Assembly].*.mm.dll and generates MONOMODDED_[Assembly].exe, which is the patched version of the assembly.

Example Patch

You've got Celeste.exe and want to patch the method public override void Celeste.Player.Added(Scene scene).

If you haven't created a mod project yet, create a shared C# library project called Celeste.ModNameHere.mm, targeting the same framework as Celeste.exe.
Add Celeste.exe, MonoMod.exe and all dependencies (.Utils, cecil) as assembly references.
Note: Make sure to set "Copy Local" to False on the game's assemblies. Otherwise your patch will ship with a copy of the game!

#pragma warning disable CS0626 // orig_ method is marked external and has no attributes on it.
namespace Celeste {
    // The patch_ class is in the same namespace as the original class.
    // This can be bypassed by placing it anywhere else and using [MonoModPatch("global::Celeste.Player")]

    // Visibility defaults to "internal", which hides your patch from runtime mods.
    // If you want to "expose" new members to runtime mods, create extension methods in a public static class PlayerExt
    class patch_Player : Player { // : Player lets us reuse any of its visible members without redefining them.
        // MonoMod creates a copy of the original method, called orig_Added.
        public extern void orig_Added(Scene scene);
        public override void Added(Scene scene) {
            // Do anything before.

            // Feel free to modify the parameters.
            // You can even replace the method's code entirely by ignoring the orig_ method.
            orig_Added(scene);
            
            // Do anything afterwards.
        }
    }
}

Build Celeste.ModNameHere.mm.dll, copy it into the game's directory and run MonoMod.exe Celeste.exe, which generates MONOMODDED_Celeste.exe.
Note: This can be automated by a post-build step in your IDE and integrated in an installer, f.e. Everest.Installer (GUI), MiniInstaller (CLI) or PartialityLauncher (GUI).

To make patching easy, yet flexible, the MonoMod patcher offers a few extra features:

  • MonoMod.MonoModRules will be executed at patch time. Your rules can define relink maps (relinking methods, fields or complete assemblies), change the patch behavior per platform or define custom modifiers to f.e. modify a method on IL-level using cecil.
  • For types and methods, to be ignored by MonoMod (because of a superclass that is defined in another assembly and thus shouldn't be patched), use the MonoModIgnore attribute.
  • Check the full list of standard modifiers with their descriptions, including "patch-time hooks", proxies via [MonoModLinkTo] and [MonoModLinkFrom], conditinal patching via [MonoModIfFlag] + MonoModRules, and a few more.

FAQ

How does the patcher work?

  • MonoMod first checks for a MonoMod.MonoModRules type in your patch assembly, isolates it and executes the code.
  • It then copies any new types, including nested types, except for patch types and ignored types.
  • Afterwards, it copies each type member and patches the methods. Make sure to use [MonoModIgnore] on anything you don't want to change.
  • Finally, all relink mappings get applied and all references get fixed (method calls, field get / set operations, ...).

How can I check if my assembly has been modded?

MonoMod creates a type called "WasHere" in the namespace "MonoMod" in your assembly:

if (Assembly.GetExecutingAssembly().GetType("MonoMod.WasHere") != null) {
    Console.WriteLine("MonoMod was here!");
} else {
    Console.WriteLine("Everything fine, move on.");
}

Note: This can be easily bypassed. More importantly, it doesn't detect changes made using other tools like dnSpy.
If you're a gamedev worried about cheating: Please don't fight against the modding community. Cheaters will find another way to cheat, and modders love to work together with gamedevs.

Am I allowed to redistribute the patched assembly?

This depends on the licensing situation of the input assemblies. If you're not sure, ask the authors of the patch and of the game / program / library.

Is it possible to use multiple patches?

Yes, as long as the patches don't affect the same regions of code.

While possible, its behaviour is not strictly defined and depends on the patching order.
Instead, please use runtime detours / hooks instead, as those were built with "multiple mod support" in mind.