MSBuild does not cooperate with Restart Manager on Windows

[hrumhurum]

Summary

Lingering MSBuild processes lock .NET assembly files with MSBuild tasks, blocking the possibility of changing them.

Background and Motivation

After dotnet build command completion, there are plenty of running dotnet processes launched with the following command line:

Module:                         dotnet.exe, 64-bit
Full path:                      C:\Program Files\dotnet\dotnet.exe

Command Line:
"C:\Program Files\dotnet\dotnet.exe" "C:\Program Files\dotnet\sdk\10.0.100\MSBuild.dll" /noautoresponse /nologo /nodemode:1 /nodeReuse:true /low:false

Those MSBuild processes are lingering around well after a build is completed.

If the build uses a 3rd party .DLL file with MSBuild tasks, the task file gets locked by one of the running dotnet processes. This creates problem for MSI installers that want to remove/modify that .DLL file.

Proposed Feature

This would not pose a problem if MSBuild could cooperate with Windows restart manager. However, as of MSBuild 18.0 / .NET SDK 10.0.100, MSBuild does not support its semantics. As a result, package installers have no clear way of tearing blocking MSBuild processes down, and this creates a painful experience for the end users if they happen to launch an installer soon enough after the last build.

Alternative Designs

No response

[KalleOlaviNiemitalo]

Guidelines for applications seems to be the documentation for what would be done at the MSBuild side. But it's not clear to me whether adding a CTRL_C_EVENT handler and/or calling RegisterApplicationRestart makes a difference in Windows Installer behaviour if MSBuild only wants the process to be terminated and not restarted.