Revert change to follow symlinks of dotnet host

[agocke]

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

[Copilot]

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))

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

Unfortunately, it seems a number of users have taken a dependency on the Windows-specific behavior.

Can we add a test case (with a comment about this) that constructs the symlink-ed apphost where the dependencies are not at the target, but are at the symlink?

[agocke]

Yes, great idea

[agocke]

@elinor-fung I believe this is ready for re-review

[elinor-fung]

Maybe split this into separate cases? Basically so that the Windows case would fail without this revert.

• Windows: app files do not exist at the target directory, only in the symlink directory
• Unix: app files exist at the target directory

[agocke]

I'm not sure I understand the Windows case. Are you suggesting that in the Windows case we should separate out the files behind the symlink? It seems like that would be the only way it would fail without the revert.

[elinor-fung]

Yeah, separate out just the apphost. I'm looking to hit the case that broke for folks - with the current test, Windows would still pass, since the files can still be resolved after following the apphost symlink since they are at the target.

For Windows, I'm thinking something like:

symlinked\
  app.exe -> target_app\app.exe
  app.dll -> app_deps\app.dll
  (other dependencies) -> app_deps\(other dependencies)

target_app\
  app.exe
  (no other files)

app_deps\
  app.dll
  (other dependencies)

[elinor-fung]

Thanks!

[agocke]

/backport to release/9.0

[github-actions]

Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/15407440566

[agocke]

/backport to release/9.0-staging

[github-actions]

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/15408385291

[agocke]

/ba-g failures are unrelated