Microsoft.Build (MSBuild)

The MSBuild Build Coordinator is a resource management system that orchestrates and enforces fair-share allocation of build nodes across multiple simultaneous MSBuild processes. It runs as a separate process (MSBuild.Coordinator) and uses named pipes for Inter-Process Communication (IPC).

Its primary functions include:

• Enforcing a global node budget: Defaults to the processor count to prevent system resource exhaustion.
• Fair-share allocation: Distributes available nodes among competing builds.
• Build health monitoring: Uses periodic heartbeats to track active builds.
• Nested grant support: Allows child processes to share a parent's node grant to prevent deadlocks.
• Auto-shutdown: The coordinator shuts down after a period of inactivity.

The Microsoft.Build.dll package provides the core APIs for interacting with MSBuild. The functionality is divided into three primary namespaces:

• Microsoft.Build.Evaluation: Used for evaluating MSBuild projects (e.g., resolving properties and items).
• Microsoft.Build.Construction: Used for creating and editing the structure of MSBuild projects (the XML representation).
• Microsoft.Build.Execution: Used for the actual execution and building of MSBuild projects.

The Microsoft.NET.StringTools package provides the Microsoft.NET.StringTools assembly, which implements common string-related functionality, specifically including features like weak interning.

Note: This package is currently intended primarily as an internal implementation detail for MSBuild and Visual Studio. If you intend to use this package for external projects, the maintainers request that you start a discussion at https://github.com/dotnet/msbuild/discussions to communicate your use cases.

BuildCheck is a feature introduced in .NET 9.0 designed to allow the MSBuild team to evangelize build best practices and provide customers with tools to formalize and distribute their own build standards. It enables the notification of problems related to build performance and security through specialized 'Checks'.

For detailed technical specifications, refer to the BuildCheck Spec.

This documentation outlines how MSBuild manages compatibility with Native AOT and Trimming through specific annotations. It details the relationship between [RequiresUnreferencedCode] (RUC) and [DynamicallyAccessedMembers] (DAM) to ensure that reflective code paths are correctly identified and guarded.

Key concepts include:

• RUC ([RequiresUnreferencedCode]): Used to mark code that relies on reflection and may fail if the target type is trimmed.
• DAM ([DynamicallyAccessedMembers]): Used to specify which members of a type must be preserved by the trimmer.
• Feature Switches: Used to gate reflective subsystems (like plugin loading or logger initialization) so they can be disabled in AOT/Trimmed environments, allowing the trimmer to safely remove those code paths.

The MSBuild repository maintains a backlog of warnings related to Native AOT and Trimming compatibility (specifically RequiresUnreferencedCode annotations). These warnings are not false positives; they indicate paths that reach subsystems not yet ready for trim/AOT environments.

When these paths are encountered in a trimmed/AOT MSBuild environment, the system is designed to fail observably rather than silently. You may encounter the following build errors:

• MSB4283: ReflectiveTaskExecutionNotSupported (via InvalidProjectFileException)
• TaskLoadFailure
• TaskInstantiationFailureError
• InvalidProjectFileException

BuildCheck operates in two primary modes:

• Live Mode: Integrates directly into the build execution (similar to compilation checks). This is the default for users opting-in to real-time checking.
• Replay Mode: Performs checks post-build by analyzing a binary log. This prevents performance impact on the actual build process and supports analyzing builds from .NET 9.0 / VS 17.12 or newer.