Repository navigation
simplify response file parsing #1665
Description
Response file parsing can currently be customized by a developer using System.CommandLine using the CommandLineBuilder.ParseRespondFilesAs(ResponseFileHandling) method. The ResponseFileHandling enum provides two modes (in addition to Disabled) but the behavior is not apparent to end users, and is occasionally surprising.
The proposal is to support only a single response file parsing behavior by removing the existing methods and supporting only enable/disable. The new behavior would follow these rules:
- Multiple-line files will be parsed treating newlines as equivalent to spaces.
- Multiple tokens on a single line will be parsed as though passed verbatim on the command line.
- Including a space within a token will now require enclosing the token in quotes, e.g.
"this is one token". - Shell-specific escaping of quotes will not be required.
- Including a space within a token will now require enclosing the token in quotes, e.g.
- Allow comment lines using a
#prefix at the beginning of the line
Open questions:
- How should quotation marks be escaped?
Activity
KathleenDollard commentedon Mar 7, 2022
What's the prior art. Multiple double quotes in C# and & in HTML?
jonsequitur commentedon Mar 7, 2022
It's inconsistent, with minor differences even among Microsoft implementations. Documentation is a bit sparse. I couldn't find any mention of escape syntax.
https://docs.microsoft.com/en-us/dotnet/visual-basic/reference/command-line-compiler/specify-response-file
https://docs.microsoft.com/en-us/cpp/build/reference/at-specify-a-compiler-response-file?view=msvc-170
https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-response-files?view=vs-2022
https://docs.microsoft.com/en-us/visualstudio/install/automated-installation-with-response-file?view=vs-2022
https://docs.microsoft.com/en-us/windows/win32/midl/response-files#:~:text=A%20response%20file%20is%20a,convenience%20for%20your%20build%20process.
marek-safar commentedon Apr 21, 2022
This is a breaking change that breaks .net6 servicing builds. Was it really intentional when there is no version bump?
Fix dotnet#1665 (dotnet#1714)