Inherit patcher types

[Nytra]

This makes pre-patcher types be inherited which matches the behavior of plugin types.

Description

There is some difference between the way plugin types and patcher types are found in assemblies.

The plugin types will search with inheritance whereas the patcher types will not.

This PR makes the plugins and patchers use the same searching code essentially.

Current plugin searching code which this PR is based off:

BepisLoader/BepInEx.Core/Bootstrap/BaseChainloader.cs

Line 112 in 29e3aeb

if (!ReferencesThisAssembly(ass))

BepisLoader/BepInEx.Core/Bootstrap/BaseChainloader.cs

Line 115 in 29e3aeb

if (ass.MainModule.GetTypeReferences().Any(r => MetadataHelper.TypeInheretsFrom(r, typeof(BepInPlugin))))

Plugin attribute code which passes the third parameter to make it use inheritance:

BepisLoader/BepInEx.Core/Contract/Attributes.cs

Line 68 in 29e3aeb

var attr = MetadataHelper.GetCustomAttributes<BepInPlugin>(td, false, true).FirstOrDefault();

Motivation and Context

I need this for my UniModFramework

How Has This Been Tested?

Tested by loading some pre-patchers and they seem to work.

Screenshots (if appropriate):

N/a

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[hazre]

I'm cool with this change as long as it doesn't break existing or future pre-patchers. Meaning it would require some extensive testing.

[Nytra]

I've tested it with Arti's FourLeafClover mod and it works, I'm not sure what else there is to test.

[EIA485]

as relevant context heres why my upstream pr was denied for now
another prepatcher mod you can test against is DeleagateRefEditing

[github-actions]

Download the artifacts for this pull request:

• BepInEx_CI.zip

[art0007i]

Well I've decided to do some testing, and I tried this setup:

PatcherA.dll defines class which inherits BasePatcher
PatcherB.dll inherits the class defined in PatcherA.dll

This works, but if I rename PatcherA.dll to zzPatcherA.dll it stops working. There's no error message or anything in the log either.

Here's a zip with the source code to both PatcherA and PatcherB and the compiled dlls that I used for this test:
Patcher.zip

[Nytra]

I mean isn't this just because PatcherB.dll references PatcherA.dll which now doesn't exist because you renamed it?

[art0007i]

oh maybe

[art0007i]

still no warning or error on that is not the best I Think

[Nytra]

Nothing in bepinex log? I'd think this would be a .NET thing not something I need to handle explicitly

[art0007i]

bepinex might be swallowing it somewhere, but nope, nothing at all in the log when the referenced assembly is missing.

only thing relevant to patcher b when it's dependancy has been renamed is this:

[Debug  :   BepInEx] Examining '/home/arti/.local/share/com.kesomannen.gale/resonite/profiles/Default/BepInEx/patchers/PatcherB.dll'

interestingly enough the patcher A still runs successfully even though it's been renamed. I haven't looked fully at the prepatcher stuff but do they put each dll in a separate load context? otherwise I think c#'s type resolution shuld find the types if they're already loaded in memory beforehand

[Nytra]

I don't think the load context would matter because it uses Cecil to get the DLL references I think