Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change how the mono search path is configured and change its default logic #57

Merged
merged 2 commits into from
May 9, 2024

Conversation

aldelaro5
Copy link
Contributor

This pr does 2 changes:

  • 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.

@ManlyMarco ManlyMarco merged commit 7c9d5c8 into NeighTools:master May 9, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants