Hang in <Exec "dotnet build"

[jhudsoncedaron]

Describe the bug

Hang in <Exec "dotnet build" ; the Exec line waits for the build server to quit due to idle timeout rather than for the build server to finish

I don't fully understand the bug but it appears to happen when dotnet test needs to start a dotnet build job. I can't run the build job inline due to a different bug. The build server needs to not be running or the bug won't reproduce.

To Reproduce

Extract attached zip file and run repro.bat ; ensure that nothing else is using .NET at the time or the repro might not work or even cause problems. You may need to close all open visual studio instances.

If your machine is more powerful than mine, you may need to add more empty console projects as dependencies to BuildToolsCollection.

net6bisect.zip

Exceptions (if any)

None. It's a hang.

Further technical details

C:\Users\jhudson\dev\scratch\net6bisect>dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.300
 Commit:    8473146e7d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support):
  Version: 6.0.5
  Commit:  70ae3df4a6

.NET SDKs installed:
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.419 [C:\Program Files\dotnet\sdk]
  5.0.408 [C:\Program Files\dotnet\sdk]
  6.0.202 [C:\Program Files\dotnet\sdk]
  6.0.300 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

C:\Users\jhudson\dev\scratch\net6bisect>

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Apostolique]

I found a workaround by changing

<Exec Command="dotnet build" />

to:

<Exec Command="powershell -Command &quot;(Measure-Command { dotnet build | Out-Default}).ToString()&quot;" />

Bit of a hack and I'm sure there are other ways to do this workaround but I didn't really want to investigate more.

One thing I noticed on my system is that builds would be fast (less than 2 seconds) right as soon as I booted but after maybe 20 seconds builds would suddenly increase by a lot (more than 48 seconds). I'm guessing there's an app that interferes with dotnet somehow but I couldn't figure out which one.

[baronfel]

I took a look at the sample repro - we really really do not suggest running MSBuild and dotnet run in the way that you have in these projects. I looked more in-depth and from what I can tell you're exceuting programs to generate assemblyinfo files that are included in your build. I strongly suggests you not do that, and instead use the built-in facility MSbuild to create these assemlbyattributes in a way that isn't convoluted and possibly breaking your build. We have comprehensive docs on this topic here, but the short form is that a project can just set some MSBuild properties to controll all of the things you're doing already:

<Project>
  <PropertyGroup>
    <AssemblyVersion>1.0.0.0</AssemblyVersion>
    <FileVersion>1.0.0.0</FileVersion>
	<Company>Cedaron Medical, Inc.</Company>
    <Product>Cento Forms product family</Product>
  </PropertyGroup>
</Project>

That should remove a lot of complexity from your build, as well as making it way faster.

[jhudsoncedaron]

@baronfel : That recommendation only works for the toy example not the real codebase. But what you are looking at there is a workaround for a problem that doesn't really exist anymore. At the time I filed this, project dependencies that were build tools didn't work at all; but they work now with a very long declaration.

[baronfel]

@jhudsoncedaron in that case an binlog would be helpful to triage what exactly is going wrong. If you are able to capture one, please submit it through VS Developer Community as a private attachment (since binlogs can contain PII) and drop a link to the Developer Community item here for follow-up.

[jhudsoncedaron]

This entire pathway was debugged on a MS support case nearly two years ago now. The problem is due to the inner dotnet build being the first one that invokes the compiler, so that process becomes the vbcs build server and Exec gets hung up waiting for the build server to shut down.

But while this case was running the other bug causing ReferenceOutputAssembly to not be honored got fixed so the solution went the other way and this Github issue got left to rot. As you found, the underlying bug is still there but pretty much doesn't matter anymore.

Until somebody finds a use case that isn't a workaround for broken project references (unlikely) this can remain closed.

[baronfel]

Instead of running dotnet build like this, the way we'd suggest you run any 'inner builds' you require is the MSBuild Task - you can ask the current build to build another project. There's documentation around how to do this here - you can set any additional properties you need (like the Configuration I see mentioned earlier in this thread), but this does so in a way that the MSBuild engine can track and understand.

Was this something that you tried in the previous support case? Do you have any links to that I can reference on my end?

[jhudsoncedaron]

The tracking number is SR #2203220060001485

Related issues:
#24434
dotnet/msbuild#4795

Besides the AssemblyInfo.cs generator we have three full on compilers in the build tree that compile domain specific languages.