MSBuild Server dogfood (#12120)

[SimaTian]

We would like to move forward with making MSBuild server default in some scenarios.
Before we do that, we need to dogfood the feature.
Initial testing suggests it works nicely - so far it works in our internal pipelines an on our local dev loop. We're also already dogfooding in aspnetcore for several months.
So sdk is one of the logical next steps we would like to take.

[Copilot]

Pull Request Overview

This PR enables MSBuild server functionality for the .NET SDK build process by setting the MSBUILDUSESERVER environment variable to 1. This change is part of dogfooding MSBuild server before making it default in certain scenarios.

• Sets MSBUILDUSESERVER=1 environment variable in SDK build pipeline templates
• Enables MSBuild server for both test template execution and main build steps

[baronfel]

@SimaTian additional places to add the env var to:

• artifacts/sdk-build-env script generation

  • sdk/eng/restore-toolset.ps1

    Line 42 in cdf3a40

    $scriptContents = @"

  • similar in restore-toolset.sh
• eng/dogfood.[sh|ps1]
• Helix test execution

  • sdk/build/RunTestsOnHelix.sh

    Line 4 in cdf3a40

    export NUGET_ENABLE_EXPERIMENTAL_HTTP_RETRY=true

  • similar in RunTestsOnHelix.ps1

[marcpopMSFT]

I assume you'll eventually want to turn this on for arcade after flighting it with a few other repos first.

[MiYanni]

@SimaTian

Failures

TemplateEngine macOS x64

This is a known failure being tracked here: #50948 (comment)

TestBuild Linux x64

Not sure what's going on here. Haven't seen this failure before with RunFileTests.Pack. @jjonescz Any ideas on this test failure?

TestBuild macOS arm64

This is a known failure being tracked here: #50784

[jjonescz]

This should be added to the sdk-build-env.ps1 too which is constructed below.

That might explain why only linux legs are currently failing and windows ones are not.

[jjonescz]

So I'm dogfooding this while investigating the failures that happen in CI. I cannot repro them so far but I noticed something:

When I run

dotnet test ./test/dotnet.Tests/ --filter "FullyQualifiedName~RunFileTests.Pack"

I normally see all the test results in the stdout.

But when I set DOTNET_CLI_USE_MSBUILD_SERVER=1 before running that same command, it seems a separate process is used to run the tests. But the original dotnet test process doesn't show any test outputs. Which also impacts my ability to inspect what is going on...

[SimaTian]

I noticed this while debugging and I agree it is annoying and problematic.
I think I will have to take a look at the way sdk launches the msbuild app for tests - server adds one layer of indirection (e.g. it spawns another process) for the build. There is supposed to be some redirect, but the tests are wired separately from the rest.

public class MSBuildCommand(
    IEnumerable<string> msbuildArgs,
    string? msbuildPath = null
) : MSBuildForwardingApp(MSBuildArgs.AnalyzeMSBuildArguments([..msbuildArgs], CommonOptions.PropertiesOption,

vs

public class MSBuildCommand : TestCommand

so maybe these are working differently?

[jjonescz]

Even though I cannot repro the failures locally, could the problem with RunFileTests.Pack be that it relies on dotnet/msbuild#12156, i.e., the virtual in-memory project should be available for MSBuild sub-tasks, and that is not working with MSBuild server?