Change how the mono search path is configured and change its default logic #57
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.