Fix dotnet host detection using GetFileNameWithoutExtension#53157
Merged
MichaelSimons merged 3 commits intodotnet:mainfrom Feb 26, 2026
Merged
Conversation
Path.GetFileNameWithoutExtension treats dot-separated suffixes as file extensions, so 'dotnet.Tests' is incorrectly identified as 'dotnet'. This causes failures when the process is a dotnet-prefixed executable rather than the actual dotnet host. Replace GetFileNameWithoutExtension with GetFileName and compare against the full executable name (e.g. 'dotnet' on Linux, 'dotnet.exe' on Windows) in all affected locations: - Muxer.cs: unify muxer filename into a single local variable - EnvironmentProvider.cs: use Constants.DotNetFileName - EnvironmentOptions.cs (dotnet-watch): fix Debug.Assert - ServerConnection.cs (Razor): fix FindDotNetExecutable - MSBuildSdkResolver.cs: unify with Constants.DotNetFileName - Constants.cs: add DotNetFileName, remove DotNetExe Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes incorrect “dotnet host” detection caused by using Path.GetFileNameWithoutExtension (which can treat dot-separated suffixes like dotnet.Tests as an extension), and updates call sites to compare against the full executable filename instead.
Changes:
- Replace
GetFileNameWithoutExtension-based dotnet-host checks withPath.GetFileNamecomparisons against the platform-specific dotnet executable name. - Introduce and use a shared
Constants.DotNetFileNameto centralizedotnetvsdotnet.exeselection. - Add a regression test ensuring dotnet-prefixed process names (e.g.,
dotnet.Tests) don’t get mistaken for the dotnet host.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| test/Microsoft.DotNet.MSBuildSdkResolver.Tests/GivenAnEnvironmentForResolution.cs | Adds a regression test for dotnet-prefixed process-name host detection; updates test class to SdkTest. |
| src/Resolvers/Microsoft.DotNet.NativeWrapper/EnvironmentProvider.cs | Updates host detection to use Path.GetFileName and Constants.DotNetFileName. |
| src/Resolvers/Microsoft.DotNet.NativeWrapper/Constants.cs | Introduces DotNetFileName (platform-specific dotnet executable filename). |
| src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs | Uses Constants.DotNetFileName when constructing muxer/dotnet paths. |
| src/RazorSdk/Tool/ServerProtocol/ServerConnection.cs | Fixes dotnet detection to use full filename rather than filename-without-extension. |
| src/Cli/Microsoft.DotNet.Cli.Utils/Muxer.cs | Fixes muxer detection to use full filename; centralizes computed muxer filename within ctor. |
| src/BuiltInTools/Watch/Context/EnvironmentOptions.cs | Updates debug assertion to validate full muxer filename instead of filename-without-extension. |
baronfel
approved these changes
Feb 25, 2026
Member
baronfel
left a comment
baronfel
left a comment
There was a problem hiding this comment.
😬
Good find - I suspect this is one of those things that would also become more clear if/when we had the unified 'path resolver' infrastructure.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
dsplaisted
approved these changes
Feb 25, 2026
Member
Author
|
/ba-g Known Linux failure. |
MichaelSimons
deleted the
fix/getfilenamewithoutextension-dotnet-detection
branch
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
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.
Summary
Multiple locations in the codebase use Path.GetFileNameWithoutExtension to check whether the current process is the dotnet host. This is incorrect because GetFileNameWithoutExtension treats any dot-separated suffix as a file extension — for example, GetFileNameWithoutExtension("dotnet.Tests") returns "dotnet", which is a false positive match.
This was discovered during the xUnit v3 migration (#52930), where tests run as standalone executables named dotnet.Tests. The test GivenAProjectToolsCommandResolver.ItWritesADepsJsonFileNextToTheLockfile was failing because Muxer incorrectly treated the dotnet.Tests process as the dotnet host, causing ProjectToolsCommandResolver.GenerateDepsJsonFile to invoke dotnet.Tests exec MSBuild.dll ... instead of the real dotnet host, resulting in:
Fix
All affected locations now use Path.GetFileName and compare against the full executable name (dotnet on Linux, dotnet.exe on Windows), matching the pattern already established in EnvironmentProvider.GetDotnetExeDirectory. Duplicate inline computations of the dotnet filename were unified into shared fields (Constants.DotNetFileName, Muxer.muxerFileName).
Testing
Added ItDoesNotMistakeDotnetPrefixedProcessForDotnetHost test that verifies GetDotnetExeDirectory falls through to PATH-based lookup when the process path is a dotnet-prefixed name like dotnet.Tests.