.NET 9 SDK introduces hang in `dotnet format` when run on Azure Pipelines in combination with NB.GV

[AArnott]

Describe the bug

dotnet format --verify-no-changes --no-restore just hangs with no output when run in this configuration:

• Azure Pipelines (local is fine)
• .NET 9 SDK (.NET 8 SDK is fine)
• With the Nerdbank.GitVersioning nuget package referenced

Working fine with .NET 8 SDK Hanging (across 2 attempts) with .NET 9 SDK

@nietras reported the same issue with their own repo, who isolated the repro to requiring both .NET 9 SDK and the Nerdbank.GitVersioning package.

In my case, the hang is on a linux build agent. For @nietras I believe it was a Windows agent. Both of us run this tool only on one agent in the pipeline.  

To Reproduce

1. Fork the repo at https://github.com/dotnet/Nerdbank.Streams.git
2. Run it under Azure Pipelines on this commit: 09b404915c9a6d4566023e3bdebbbf8b08eebf42

Exceptions (if any)

Further technical details

@nietras also shared the diagnostic output:

D:\agent\_work\_tool\dotnet\dotnet.exe format --verify-no-changes -v diagnostic
  The dotnet runtime version is '9.0.0'.
  The dotnet CLI version is '9.0.100'.
  Using MSBuild.exe located in 'D:\agent\_work\_tool/dotnet\sdk\9.0.100\'.
  Formatting code files in workspace 'D:\agent\_work\210\s\Test.sln'.
  Loading workspace.
    Determining projects to restore...
  Restored D:\agent\_work\210\s\src\XYZ\XYZ.csproj (in 198 ms)

`dotnet --info` output

``` MSBuild version: 17.12.7+5b8665660 Runtime Environment: OS Name: ubuntu OS Version: 22.04 OS Platform: Linux RID: linux-x64 Base Path: /opt/hostedtoolcache/dotnet/sdk/9.0.100/ .NET workloads installed: There are no installed workloads to display. Configured to use loose manifests when installing new manifests. Host: Version: 9.0.0 Architecture: x64 Commit: 9d5a6a9aa4 .NET SDKs installed: 9.0.100 [/opt/hostedtoolcache/dotnet/sdk] .NET runtimes installed: Microsoft.AspNetCore.App 9.0.0 [/opt/hostedtoolcache/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 8.0.11 [/opt/hostedtoolcache/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 9.0.0 [/opt/hostedtoolcache/dotnet/shared/Microsoft.NETCore.App] Other architectures found: None Environment variables: DOTNET_ROOT [/opt/hostedtoolcache/dotnet] global.json file: /home/vsts/work/1/s/global.json Learn more: https://aka.ms/dotnet/info Download .NET: https://aka.ms/dotnet/download Mono JIT compiler version 6.12.0.200 (tarball Tue Jul 11 21:37:50 UTC 2023) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug Interpreter: yes LLVM: yes(610) Suspend: hybrid GC: sgen (concurrent by default) ```

[dotnet-issue-labeler[bot]]

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.

[dotnet-issue-labeler[bot]]

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.

[AArnott]

Nerdbank.GitVersioning is a build-related nuget package that adds msbuild targets to projects. But I wouldn't expect it to ever hang (it never has before this), nor do I expect it to do anything special in a dotnet format context.

[KalleOlaviNiemitalo]

Perhaps strace could show whether it's blocked in a system call on the Linux agent, e.g. trying to write something to a full pipe.

I wonder if the MSBuild terminal logger is causing the hang somehow, even though Azure Pipelines should not be detected as an "interactive" terminal session. Could try disabling it with the environment variable.

[AArnott]

Thanks for the suggestion, @kalleolaviniemitalo. It didn't work though.

[AArnott]

This workaround has proven effective, but hacky. TLDR: make NB.GV a conditional dependency, and set an env variable to turn it off around the dotnet format command invocation.