Revert change to follow symlinks of dotnet host #115315
Open
+63
−18
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dotnet#99576 changed the host to first resolve symlinks before resolving the application directory. This means that relative loads happen relative to the pointed-at file, not the symbolic link. This was a breaking change made to match the symbolic link behavior on all platforms. Unfortunately, it seems a number of users have taken a dependency on the Windows-specific behavior. This PR reverts the change and puts back in place the old Windows behavior.
There was a problem hiding this comment.
Pull Request Overview
This PR reverts the changes made in pull request #99576, restoring the Windows-specific symlink behavior for the dotnet host. The changes update native functions to use fullpath instead of realpath and update tests to expect failure when running behind symlinks.
- Reverts use of pal::realpath to pal::fullpath in fxr_resolver.cpp and corehost.cpp.
- Adjusts HostActivation.Tests in SymbolicLinks.cs to reflect the reverted behavior.
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/native/corehost/fxr_resolver.cpp | Replaces realpath with fullpath for handling app-relative dotnet roots. |
| src/native/corehost/corehost.cpp | Replaces realpath with fullpath when resolving the host executable path. |
| src/installer/tests/HostActivation.Tests/SymbolicLinks.cs | Updates test expectations to verify failure and appropriate error messages when symlink issues occur. |
Comments suppressed due to low confidence (4)
src/installer/tests/HostActivation.Tests/SymbolicLinks.cs:40
- Verify that the updated test expectation for failure when running the application behind a symlink accurately reflects the restored behavior.
.Should().Fail()
src/installer/tests/HostActivation.Tests/SymbolicLinks.cs:151
- Double-check that the expected error message containing the dynamically generated path remains accurate and robust with potential directory structure changes.
.Should().Fail()
src/native/corehost/fxr_resolver.cpp:98
- Ensure that using pal::fullpath in place of pal::realpath correctly reverts to the intended Windows-specific behavior as described in the PR.
if (search_app_relative && pal::fullpath(app_relative_dotnet_root))
src/native/corehost/corehost.cpp:131
- Confirm that switching to pal::fullpath properly restores the expected executable path resolution for Windows.
if (!pal::get_own_executable_path(&host_path) || !pal::fullpath(&host_path))
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
This was referenced May 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
#99576 changed the host to first
resolve symlinks before resolving the application directory. This means
that relative loads happen relative to the pointed-at file, not the
symbolic link. This was a breaking change made to match the symbolic
link behavior on all platforms.
Unfortunately, it seems a number of users have taken a dependency on the
Windows-specific behavior. This PR reverts the change and puts back in
place the old Windows behavior.