Fix working directory of simple file-based apps#51828
Fix working directory of simple file-based apps#51828jjonescz merged 2 commits intodotnet:release/10.0.2xxfrom
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR fixes the working directory behavior for simple file-based apps (.cs files run directly without a project file) to make it consistent with project-based apps. Previously, file-based apps always had their working directory set to the directory containing the source file, ignoring the process's current working directory.
- Removes hardcoded working directory override in
CreateCommandForCscBuiltProgram - Adds comprehensive tests verifying working directory behavior across different build levels (CSC-only, MSBuild, none)
- Verifies that
AppContext.GetData("EntryPointFileDirectoryPath")still correctly returns the entry point file's directory
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/RunCommand.cs | Removes .WorkingDirectory(Path.GetDirectoryName(entryPointFileFullPath)) from CreateCommandForCscBuiltProgram to allow working directory to default to current directory instead of being hardcoded to the entry point file's directory |
| test/dotnet.Tests/CommandTests/Run/RunFileTests.cs | Adds two new test methods (WorkingDirectory and WorkingDirectory_CscOnly_AfterMSBuild) and updates the Build helper method to support custom working directory testing |
| var commandSpec = new CommandSpec(path: exePath, args: ArgumentEscaper.EscapeAndConcatenateArgArrayForProcessStart(args)); | ||
| var command = CommandFactoryUsingResolver.Create(commandSpec) | ||
| .WorkingDirectory(Path.GetDirectoryName(entryPointFileFullPath)); | ||
| var command = CommandFactoryUsingResolver.Create(commandSpec); |
There was a problem hiding this comment.
It looks like removing the WorkingDirectory call just causes the ordinary logic for deciding the working directory of a command to take over? Is that right?
There was a problem hiding this comment.
Yes, basically it remains null which means "current directory". In the case of the simple CSC-only optimized build path, there is no way to override that, which is fine. It can only be overridden via MSBuild property but that wouldn't hit the optimized CSC-only path.
|
@333fred for another review, thanks |
|
/backport to release/10.0.1xx |
|
Started backporting to |
Fixes #51778.