[release/10.0] Load handler DLL with load dir on the path #63781
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.
Backport of #63773 to release/10.0
/cc @adityamandaleeka
Load handler DLL with load dir on the path
Description
This change updates the handler DLL load call from
LoadLibrary
toLoadLibraryEx
with the flagsLOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
The handler DLL exports
CreateApplication
as a forwarded export to an architecture-specific DLL. The plainLoadLibrary
does not search the handler’s directory when resolving that forwarder. As a result, the loader fails to locate the arch-specific DLL and the scenario breaks (the user gets a 500 error).Fixes #63772
Customer Impact
Apps may fail to start because the arch-specific implementation for the forwarded export isn't found.
Regression?
This bug was introduced in .NET 10 Preview 2 as part of #59483
Risk
Localized change to one load site. Only adds the handler's directory to the probing path for that module's dependency resolution and does not enable PATH/CWD, nor change process-wide state.
Verification
Packaging changes reviewed?