Closed tokizr closed 1 year ago
That is definitely unexpected. Can you take a trace of filesystem and process activity using procmon while you reproduce the issue, and share that? Make sure you're not running other processes in the background or you may share more data than you want to.
Specifically the expected flow here is:
MSBuild.exe
writes the contents of the Exec
to a temporary .cmd
file.MSBuild.exe
launches cmd.exe
, pointed to that filecmd.exe
should read the file and run its intrinsic echo
command, writing to File.txt
cmd.exe
should exit with code 0
(success)I'd love to see where that's going wrong!
One other potentially-relevant factor: are you using antivirus software on this machine? What kind? Is the source directory excluded in any way?
Over the week a had a little bit of time to investigate this further and test other computers (where I could not reproduce the problem).
The real problem seems to be cmd
itself (somehow), I debugged the Task and the temporary cmd files is for example "C:\Users\Daniel^ Keen\AppData\Local\Temp\MSBuildTempDaniel^ Keen\tmpf32eed21384741ba949516fa339d924c.exec.cmd"
. I can see the correct commands inside that file.
For some reason just running this command (with "C:\WINDOWS\system32\cmd.exe" /Q /D /C
like the task does) produces no results, in fact even if I delete the directory it still runs without any complaint (%ERRORLEVEL%
is 0). If I take only the cmd file path and paste that in the command prompt ( the part after the /C
switch) then it works fine. It does not seem to be the case that there are problems with the path otherwise I'd expect cmd to complain.
To answer your questions I'm only running the built-in Windows Security on Windows 10 21H2, I do have FortiClient for work but all functions outside of it's VPN should be disabled. I don't have either the test or temp directories excluded from scanning (tried adding that to the exclusion list but the result was the same).
I'm a little concerned about sharing a procmon capture because it seems to capture a ton of other information, but if you'd still find it valuable I can provide it.
I'll try Updating to 22H2 or Windows Repair to see if it helps, but if you have ever seen anything like this I would appreciate any hints you may have.
I have to concede that this does not seem related to MSBuild itself in the end, but to that temporary folder which is somehow haunted 👻. You may close the issue if you find it best.
FYI I just tried another account on the same PC that has no spaces in the user name (and therefore no spaces in the path) and it works fine there, so it is related to the spaces somehow (and possibly to the ^
escapes).
Could be https://github.com/dotnet/msbuild/commit/7f3a30cd04aa884699b7980a9209aade28f1eca2 then? It changes the temp folder to have Environment.UserName
in the path.
Very plausible--@forgind can you take a look?
Hmm...I'm having some trouble reproducing your problem. I created a default csproj and added the WriteOut target as in your snippet. I started without a space anywhere in the path and built the project with current main, specifying /t:WriteOut
, and it built successfully and created File.txt as expected. Then I added a space to the folder containing the csproj, and it still built successfully, and the same was true when I put the csproj in a folder without in a space in a folder with a space.
Since I was on windows, I next switched to Linux (Ubuntu) and built current main there as well, executing that MSBuild on a csproj in folder 81 59
and specifying /t:WriteOut. It created File.txt as expected.
What am I doing wrong?
@Forgind did you try building the project with a user whose username that has space in it?
I tried overwriting User
, Name
, TMP
, and TEMP
to have spaces in them, and that didn't change anything. I think that's equivalent; am I wrong?
@Forgind Environment.UserName
is implemented via GetUserNameExW
, I'd assume that function doesn't look at the env vars.
I tried creating a local user Test User
and I can't reproduce the problem.
procmon shows the cmd.exe getting launched like this:
Parent PID: 316, Command line: "C:\WINDOWS\system32\cmd.exe" /Q /D /C "C:\Users\Test^ User\AppData\Local\Temp\MSBuildTempTest^ User\tmp4c026317e13d4070963f7f4a660c6542.exec.cmd", Current directory: C:\Users\Test User\
and the File.txt shows up with the expected content.
This is on Windows 11 21H2 (Build 22000.1219)
This issue is marked as stale because feedback has been requested for 30 days with no response. Please respond within 14 days or this issue will be closed due to inactivity.
This issue was closed due to inactivity. If you can still reproduce this bug, please comment with the requested information, detailed steps to reproduce the problem, or any other notes that might help in the investigation.
Issue Description
In msbuild 17.4 the
Exec
task does not fail but does not execute the command.Steps to Reproduce
A minimal C# project:
When running
dotnet build -t:WriteOut
not file is created if the .Net 7 SDK or msbuild 17.4 from Visual Studio (Dev Cmd) is used. Previous versions create the file as expected.Expected Behavior
A file is created because the command executes.
Actual Behavior
No file is created, the command does not seem to execute.
Versions & Configurations
Tested both
MSBuild version 17.4.0+18d5aef85 for .Net
(.Net 7.0.100 SDK) &MSBuild version 17.4.0+18d5aef85 for .NET Framework
(VS 2022 17.4.0)I have noted this issue in both C++ & C# projects. Commands I had fail were varied. The command in the STR above is just the simplest I found that was easy to verify the outcome of.
So far I have worked around this through the creation of my own custom exec task.