Context and Motivation

Currently, the .NET product is organized in multi-repository fashion, with each of its components (runtime, roslyn, SDK, …) living in dedicated git repositories. While this code organization simplifies development of the individual components, construction of the final product requires complex orchestration to flow binary dependencies between the individual product repos, as well as human effort to get a coherent product build. This way of building the .NET product is called Microsoft’s official build.

Source-build, yet another way of building the .NET product, is used by our Linux partners (Red Hat, Canonical) to build and ship .NET in their distros, satisfying strict requirements of building the product without binary dependencies. Maintaining both these methodologies is expensive.

The Unified Build project aims to reduce the costs of the .NET servicing releases as well as the release time by providing a single (virtual) repository that with all the code and assets needed to build the entire product. Focusing on the source-build philosophy (aggregate code base is the source-of-truth) as the way that the community and Microsoft produce the product will drastically improve development operations, servicing, and community interaction.

.NET Unified Build is a theme for the Germanium semester.

Details can be found in the "Unified Build (Theme)" document. The scenarios listed below are pulled from this document and will be represented as linked work items in this project.

Costing

Cost Label	Effort Is
S	< 4 person weeks
M	4-10 weeks
L	10 – 20 weeks
XL	> 20 weeks

Scenarios

Microsoft and its partners can develop and build a .NET distribution with minimal orchestration
- Microsoft can produce a shippable .NET 9 build in (5-6 hours), significantly less than .NET 8 (16 hrs).
- Release retrospective items classified as “Build” drop by 50% in .NET 9 as compared to .NET 8.
- A shippable build is produced from a single commit in a single source repo.
Developers can efficiently work on the product
- Cross-stack repository changes can be done in a single commit.
Microsoft, its partners, and community developers can validate the complete product
- Distro partners can decommission their existing smoke tests if they desire, and still have confidence in shipping the product.

Areas

Implement Vertical Build of the .NET product - P1/XL

This effort aims to build the .NET product as a series of vertical builds for each platform from source rather than through a complex graph of binary dependencies resulting from building the individual product repos separately. This build methodology follows the current way of source-building the product, although with less strict requirements on using binaries during the build process.

The Vertical Builds area is the fundamental part of the Unified Build project and by far the largest in scope. It also requires significant expertise in the product repos infrastructure. It's a prerequisite for the main two scenarios of this theme (Building the .NET product with minimal orchestration and Efficient product development).

Vertical Build Proofs of Concept for each vertical (Windows, Linux, MacOS, SDK Workloads) - Uncover hidden problems with building the product for each platform in a single build without requiring cross-platform build assets.
Vertical Builds Design - Leverage the finding of the vertical build PoC works to design vertical builds for each platform properly, with the minimal set of join points.
- https://github.com/dotnet/source-build/issues/3708
- https://github.com/dotnet/source-build/issues/3739
Enable Vertical Builds - Implementation of the vertical builds design with the new set of join points.
- https://github.com/dotnet/source-build/issues/3902
Cross-builds Design - Design for cross-arch or cross-platform builds and determine how to define cross-build behavior.
- https://github.com/dotnet/source-build/issues/3671

Source-Build Support for Unified Build - P2/XL

Since the Unified Build aims to adopt the source-build approach to building the .NET product on all platforms, there are certain improvements in the current .NET source-build implementation required to adopt the Unified Build methodology across all supported platforms and provide a good developer experience. Improvements in this area are mainly centered around the "Efficient product development" scenario.

Eliminate Source Edits During Build - Improve developer experience of the unified build by eliminating source edits during the build
- https://github.com/dotnet/source-build/issues/3664
Parallel Build Support - Improve unified build performance by supporting parallel builds
- https://github.com/dotnet/source-build/issues/3608
Remove Inner Clone - Improve developer experience and performance of the unified build by not creating an inner repo clone during the build
- https://github.com/dotnet/source-build/issues/3072
Incremental Build Support
- https://github.com/dotnet/source-build/issues/3666
Support for Multi-band SDKs - Support for multiple SDK bands in the VMR and unified build
- https://github.com/dotnet/source-build/issues/3667

Product Validation - P1/L

Complementary to the individual product repo testing, Product Validation is centered around providing confidence in the final product. The improvements in this area focus on building infrastructure and scenario tests that could be used to validate the installed .NET product.

Scenario tests in VMR - End-to-end scenario tests executed on already installed .NET product.
PR Validation - Definition and implementation of the set of tests that would be executed as part of the VMR PR validation.
- https://github.com/dotnet/source-build/issues/3823
- https://github.com/dotnet/source-build/issues/3822
Product Validation Tooling
- https://github.com/dotnet/source-build/issues/3819

Product Construction Improvements - P1/XL

Product construction improvements are centered around infrastructure and tooling required to synchronize the code between the individual product repos and the .NET Virtual Monolithic Repository). Similar to the Vertical Builds, improvements in this area are a prerequisite to the main scenarios ("Building the .NET product with minimal orchestration" and "Efficient product development") of this theme.

VMR Backflow design - Design for the backflow from the VMR to the individual product repositories.
- https://github.com/dotnet/arcade-services/issues/2714
VMR Backflow tooling - Implementation of the core functionality and CLI tooling for the VMR backflow in to the product repos.
- https://github.com/dotnet/arcade-services/issues/2996
Dependency Flow Service - Implementation of the new .NET Product Construction service, that will be extending the current dependency flow and BAR design.
- https://github.com/dotnet/arcade-services/issues/3168
- https://github.com/dotnet/arcade-services/issues/2994
Maestro Integration - Integration of the new dependency flow service with Maestro++.
- https://github.com/dotnet/arcade-services/issues/2995
Dependency Flow Switch Preparation - Preparation for switching from the existing multi-layered product dependency flow to the new flat dependency flow between VMR and product repos.
- https://github.com/dotnet/arcade-services/issues/3169
Dependency Flow Switch - Switch to the new flat dependency flow between VMR and product repos.
- https://github.com/dotnet/arcade-services/issues/3170

Release Infrastructure support for the Unified Build - P1/XL

As the Unified Build redefines the methodology of building and assembling the .NET product, the release infrastructure needs to be extended to allow for releases from both the current Microsoft build and the new Unified Build of the .NET product.

Release infra investigation & design - Design for changes necessary to enable releases off of the VMR.
- https://github.com/dotnet/source-build/issues/3753
Identify Repo Dependencies - Identification of the dependencies between product repos and the layout used to stage the product assets for release.
Staging / Release Pipeline - Updates to the current release infrastructure, namely the staging and release pipelines to be able to base releases both off the current dependency flow for .NET8 and the VMR for .NET9.
- https://github.com/dotnet/release/issues/776

dotnet / source-build

.NET Unified Build (Theme) #3926