Rethinking how .NET Builds and Delivers Software

Following my previous discussion on .NET’s build and shipping processes, I was hopeful the topic was settled. I believed we had achieved a good balance between distributed repo development and rapid product assembly. This progress allowed infrastructure teams to shift focus to security, standardization, and new feature support.

However, a year and a half later, new challenges emerged. We faced questions about the costs of maintaining multiple major .NET versions and SDK bands each month, managing timely updates, and handling urgent fixes. The responses we received were discouraging: high costs, long build times—up to 36 hours or more—and the growing burden of infrastructure upkeep. Achieving full stack development was increasingly complex and resource-intensive.

These issues prompted us to reconsider our approach. We embarked on the Unified Build project—aiming to streamline product development by creating a “virtual monolithic” repository and consolidating build processes into structured vertical builds. This system still allows contributors to operate outside the main repository, maintaining flexibility.

The story of .NET’s evolving build infrastructure begins with its origins in the closed-source .NET Framework and Silverlight. Launched as open source between 2015 and 2016, the ecosystem quickly expanded into multiple repositories: CoreCLR for runtime, CoreFX for libraries, Core-Setup for packaging, and later components like ASP.NET Core and Entity Framework Core. This modular setup facilitated development but increased complexity.

Because .NET is composed of interdependent repositories that must come together rapidly for release, traditional distributed development—which resembles a producer-consumer chain—becomes inefficient at scale. While effective in autonomy, this model struggles with coordination and speed when applied to a cohesive product like .NET.

To address these challenges, the Unified Build project introduces a new production method, leveraging Linux distribution’s Source Build technology. This approach consolidates components into a unified process, reducing overhead and improving build times. Early results demonstrate faster, more manageable releases, and a more sustainable development workflow.

In summary, .NET’s evolution reflects ongoing efforts to balance component independence with the need for efficient, coordinated product delivery. The Unified Build approach promises to reduce complexity, lower costs, and accelerate release cycles, ensuring .NET remains agile and robust.

FAQs

Q: Why did .NET need to change its build process?
A: To reduce build complexity, costs, and time, enabling faster and more efficient releases.

Q: What is the Unified Build project?
A: It’s an initiative to unify .NET’s product construction into a single, streamlined process using virtual repositories and vertical builds.

Q: How does Source Build technology improve the process?
A: It consolidates component builds, minimizes overhead, and speeds up release cycles by mimicking the Linux distribution approach.

Q: Will this change affect developers and contributors?
A: Yes, it makes builds faster and easier to manage, while still allowing contribution outside of the main repository.

Q: What benefits will users see from these improvements?
A: More frequent, reliable updates with reduced build-related delays, improving overall user experience and product stability.