Description

This pr backports the Doorstop 4 upgrade master has to v5-lts.

It also upgrades UnityDoorstop.Unix to UnityDoorstop as they both got merged after v6 pre1 came out. As a result, there's now 5 build zips produced instead of 3:

• win_x64
• win_x86
• linux_x64
• linux_x86
• macos_x86

This follows the current distribution scheme master has.

Motivation and Context

While it technically introduce a relatively minor breaking change (see below for details on what it is and why I consider it minor), Doorstop 4's main feature that makes it quite a huge deal compared to 3 is the ability to have a debugging server running without the need of DnSpy. This allows a more reliable, flexible and interesting debugging scheme: you are now able to debug the game's assemblies using recompiled sources without the messiness that is turning the build into a debug build or using DnSpy. While DnSpy has been working for lots of people it has shortcomings that makes the doorstop 4 method appealing:

• Doorstop 4 debugging works on all platform and IDEs that supports regular unity remote debugging while dnspy debugging is windows only and can't be used with an IDE (which is a disadvantage as IDEs tends to have more code analysis and debugging features)
• DnSpyEx uses an older version of ILSpy that may give poor code quality compared to newer ILSpy versions (I should note that this is being worked on by the DnSpyEx's maintainer, but as of this PR, it's still a problem)
• For very large methods, DnSpy (and DnSpyEx) can offer terrible performance when debugging. I personally have to deal with a 20k LOC coroutine that happens to be very essential to the game and DnSpyEx chugs for minutes to hit a breakpoint while it's instant using an IDE like vs or rider (and I suspect vscode would work too, but I haven't tested it)
• It doesn't require to make a patched mono if one didn't exist at the time the DnSpy repos was archived

The one drawback with this method is it requires to use recompiled sources to debug the game meaning if the decomp isn't recompilable, it needs to be sanitised. I happen to deal with a game where I don't need to do this, but from what I have been hearing, this case, while uncommon, isn't unique. Also, this only works for games using the new mono shipped as stable in unity version 2018.x and up, it doesn't work for the older one, but this was a limitation of doorstop so not loss here.

For debugging plugins, this also offers an alternative to DnSpy, but without needing to turn the release build into a debug one which can be a bit messy as it requires lots of files to be overwritten while doorstop 4 debugging doesn't.

How Has This Been Tested?

I have been using a v5 build equivalent to the win_x64 one produced by this pr for about 1.5 years with no issues on a 2018.4.12f1 unity mono game running via wine/proton.

This of course isn't exhaustive, but I made sure to follow the similar distribution scheme than what master did so everything should work, but I do recommend to gut check this.

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)

I should note what I mean by there's a breaking change: if someone was launching BepInEx externally via CLI, doorstop 4 changes how the args are passed in. This means that if someone had say a script or something that was launching with custom args, they would no longer be recognised after this PR. The config file technically is breaking, but realistically, if one does upgrade, the ini/sh files would also be replaced so it's not in practice breaking in reality. It's only for CLI args that it is.

However, it seems to me that this is minor: realistically, if someone would upgrade from v5, this doesn't seems to be a huge deal. Most users seems to not necessarily update v5 to their latest and if they did, the change only involves changing the name of the args.

No features is actually lost from this upgrade, only 2 features are gained:

• The debug server mentioned above
• The ability to specify a custom corlib path (this I found to be useful in this EXTREMELY niche usecase where I can upgrade the game's mono runtime without needing to overwrite the corlib as they can be in a separate directory)

Checklist:

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