Revert the breaking change where the target assembly's parent directory was always added to the mono search path, it no longer does it with this pr
To compensate for the above, add the ability for the search path override settings to support for more than 1 path. The paths must be split by the same OS dependant separator that mono uses
This is followed by a regression that came up in BepInEx where an assembly hook load couldn't work due the assembly of interest being preloaded due to the search path's default. This pr brings back the flexibility of allowing the target assembly to hook on loading assemblies located on the same folder.
However, if it was just a revert, it would now become annoying to opt into it because the mono override path setting only supported a single path to add. For this reason, I implemented support to have multiple paths in that setting.
The path splitting part isn't a breaking change: the format is backwards compatible if no separator was defined and it's not possible a separator existed in the path because mono was always splitting on the same separators internally. Effectively, it makes it non breaking on any path that can work, it just adds the feature.
The default behavior change however CAN be breaking if there was the expectation that this was the default. However, it's not something that can't be fixed thanks to the multiple search paths support so it's something that can be mentioned in the release note just in case.
I tested this using bepinex v5 on Windows and Linux with a couple of different cases. I made the parsing resilient against leading, trailing or duplicate separators.
This pr does 2 changes:
This is followed by a regression that came up in BepInEx where an assembly hook load couldn't work due the assembly of interest being preloaded due to the search path's default. This pr brings back the flexibility of allowing the target assembly to hook on loading assemblies located on the same folder.
However, if it was just a revert, it would now become annoying to opt into it because the mono override path setting only supported a single path to add. For this reason, I implemented support to have multiple paths in that setting.
The path splitting part isn't a breaking change: the format is backwards compatible if no separator was defined and it's not possible a separator existed in the path because mono was always splitting on the same separators internally. Effectively, it makes it non breaking on any path that can work, it just adds the feature.
The default behavior change however CAN be breaking if there was the expectation that this was the default. However, it's not something that can't be fixed thanks to the multiple search paths support so it's something that can be mentioned in the release note just in case.
I tested this using bepinex v5 on Windows and Linux with a couple of different cases. I made the parsing resilient against leading, trailing or duplicate separators.