Fix dotnet-run-file up-to-date checks across symlinks

[jjonescz]

Fixes #52063.

[Copilot]

Pull request overview

This PR fixes an issue where dotnet run with file-based programs incorrectly treated files as up-to-date when they were modified through symbolic links. The fix ensures that timestamp checks resolve symlinks to their final targets, so modifications to the target file are properly detected.

Key changes:

• Added ResolveLinkTarget helper to resolve symlinks before checking file modification times
• Applied the fix to both entry point files and implicit build files
• Added comprehensive test coverage for symlink scenarios

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs	Added symlink resolution logic to up-to-date checks, resolving both entry point and implicit build files to their final targets before comparing timestamps
test/dotnet.Tests/CommandTests/Run/RunFileTests.cs	Added four new test cases covering symlink scenarios: basic up-to-date checks, CSC-only optimization, CSC-after-MSBuild optimization, and EntryPointFilePath behavior with symlinks

[333fred]

Perhaps ResolveLinkTargetOrSelf, to differentiate from FileSystemInfo.ResolveLinkTarget?

[RikkiGibson]

Might be good to exercise the returnFinalTarget behavior, e.g. symlink2 links to symlink1 links to original file, ensuring that symlink2 has correct up to date behavior with respect to original file.

[RikkiGibson]

What is the behavior of symlinks with respect to implicit build files?

Is it expected that different implicit build files would be brought in, when running dotnet build app/app.cs versus dotnet build link/app?

.
├───app
│       app.cs
│       Directory.Build.props
│
└───link
        app (symlink to ../app/app.cs)
        Directory.Build.props

I would personally find it a bit strange if the different invocations used different implicit build files. My hope would be that we would resolve the symlink very early on in this process, and consistently use the same "implicit build files" whether we are building the symlink or the original thing.

It might also be worth checking what dotnet build MyProjectSymlink.csproj does.

Possibly the behavior I am asking for is already present and I missed it. Apologies if that is the case.

[jjonescz]

It might also be worth checking what dotnet build MyProjectSymlink.csproj does.

If the project is symlinked, it's as if it was copied (so dir.build.props are taken from the symlink's directory, not its target; i.e., different build files are brought in for dotnet build original.csproj and dotnet build linked.csproj, but that looks expected to me in this case). I'm not sure file-based apps should have the same behavior, but they currently do. It feels like an orthogonal issue though. But I can add a test.

[RikkiGibson]

Thank you for adding the test. I think no need to change behavior in this PR. We can see if anyone complains about this behavior during the upcoming dev cycle, and decide at that point whether there is motivation to make a change.

[jjonescz]

/ba-g known failures