Exec Task does not work in version 17.4

[tokizr]

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:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <Target Name="WriteOut">
    <Exec Command='echo Foo >> File.txt'/>
  </Target>
</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.

[rainersigwald]

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:

1. MSBuild.exe writes the contents of the Exec to a temporary .cmd file.
2. MSBuild.exe launches cmd.exe, pointed to that file
3. cmd.exe should read the file and run its intrinsic echo command, writing to File.txt
4. 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?

[tokizr]

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.

[tokizr]

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).

[akoeplinger]

Could be https://github.com/dotnet/msbuild/commit/7f3a30cd04aa884699b7980a9209aade28f1eca2 then? It changes the temp folder to have Environment.UserName in the path.

[rainersigwald]

Very plausible--@forgind can you take a look?

[Forgind]

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?

[rainersigwald]

@Forgind did you try building the project with a user whose username that has space in it?

[Forgind]

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?

[akoeplinger]

@Forgind Environment.UserName is implemented via GetUserNameExW, I'd assume that function doesn't look at the env vars.

[akoeplinger]

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)

[ghost]

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.

[ghost]

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.