dotnet/dotnet - Home of the .NET VMR

This repository is a Virtual Monolithic Repository (VMR) which includes all the source code and infrastructure needed to build the .NET SDK.

What this means:

Monolithic - a join of multiple repositories that make up the whole product, such as dotnet/runtime or dotnet/sdk.
Virtual - a mirror (not replacement) of product repos where sources from those repositories are synchronized into.

In the VMR, you can find:

source files of each product repository which are mirrored inside of their respective directories under src/,
tooling that enables building the whole .NET product from source on Linux platforms,
small customizations, in the form of patches, applied on top of the original code to make the build possible,
[in future] E2E tests for the whole .NET product.

Just like the development repositories, the VMR will have a release branch for every feature band (e.g. release/8.0.1xx-preview1). Similarly, VMR's main branch will follow main branches of product repositories (see Synchronization Based on Declared Dependencies).

More in-depth documentation about the VMR can be found in VMR Design And Operation. See also dotnet/source-build for more information about our whole-product source-build.

Goals

The main purpose of the dotnet/dotnet repository is to have all source code necessary to build the .NET product available in one repository and identified by a single commit.
The VMR also aims to become the place from which we release and service future versions of .NET to reduce the complexity of the product construction process. This should allow our partners and and 3rd parties to easily build, test and modify .NET using their custom infrastructure as well as make the process available to the community.
Lastly, we hope to solve other problems that the current multi-repo setup brings:
- Enable the standard down-/up-stream open-source model.
- Fulfill requirements of .NET distro builders such as RedHat or Canonical to natively include .NET in their distribution repositories.
- Simplify scenarios such as client-run testing of bug fixes and improvements. The build should work in an offline environment too for certain platforms.
- Enable developers to make and test changes spanning multiple repositories.
- More efficient pipeline for security fixes during the CVE pre-disclosure process.

We will achieve these goals while keeping active coding work in the separate repos where it happens today. For example: ASP.NET features will continue to be developed in dotnet/aspnetcore and CLR features will be continue to be developed in dotnet/runtime. Each of these repos have their own distinct communities and processes, and aggregating development into a true mono-repo would work against that. Hence, the "virtual" monolithic repo: the VMR gives us the simplicity of a mono-repo for building and servicing the product, while active development of components of that product stays in its various existing repos. The day to day experience for typical contributors will not change.

Limitations

This is a work-in-progress. There are considerable limitations to what is possible at the moment. For an extensive list of current limitations, please see Temporary Mechanics.
See the Unified Build roadmap for more details.

Supported platforms

The VMR only supports .NET 8.0 and higher. Additionally, source-build currently supports Linux only.
It is expected that Mac and Windows will be supported in the .NET 9.0.

For the latest information about Source-Build support for new .NET versions, please check our GitHub Discussions page for announcements.

Online build only

Building the product offline is not fully working at the moment. The --online switch is needed when building the VMR as not all dependencies are currently built from source.

Code flow

For the time being, the source code only flows one way - from the development repos into the VMR. More details on this process:

We expect the code flow to start working both ways in the .NET 9 timeframe. See the Unified Build roadmap for more details.

Contribution

At this time, the VMR will not accept any changes and is a read-only mirror of the development repositories only. Please, make the changes in the respective development repositories (e.g., dotnet/runtime or dotnet/sdk) and they will get synchronized into the VMR automatically.

Dev instructions

Please note that this repository is a work-in-progress and there are some usability issues connected to this. These can be nuisances such as some checked-in files getting modified by the build itself and similar. For the latest information about Source-Build support, please watch for announcements posted on our GitHub Discussions page.

Prerequisites

The dependencies for building .NET from source can be found here. In case you don't want to / cannot prepare your environment per the requirements, consider using Docker.

Building

Clone the VMR

git clone https://github.com/dotnet/dotnet dotnet-dotnet

Prep the source to build on your distro
This downloads a .NET SDK and a number of .NET packages needed to build .NET from source.
```
cd dotnet-dotnet
./prep.sh
```
Build the .NET SDK
```
./build.sh --clean-while-building --online
```
This builds the entire .NET SDK from source. The resulting SDK is placed at artifacts/x64/Release/dotnet-sdk-9.0.100-your-RID.tar.gz.

Currently, the --online flag is required to allow NuGet restore from online sources during the build. This is useful for testing unsupported releases that don't yet build without downloading pre-built binaries from the internet.

Run ./build.sh --help to see more information about supported build options.

(Optional) Unpack and install the .NET SDK

mkdir -p $HOME/dotnet
tar zxf artifacts/[your-arch]/Release/dotnet-sdk-9.0.100-[your-RID].tar.gz -C $HOME/dotnet
ln -s $HOME/dotnet/dotnet /usr/bin/dotnet

To test your source-built SDK, run the following:

dotnet --info

Building using Docker

You can also build the repository using a Docker image which has the required prerequisites inside. The example below creates a Docker volume named vmr and clones and builds the VMR there.

docker run --rm -it -v vmr:/vmr -w /vmr mcr.microsoft.com/dotnet-buildtools/prereqs:centos-stream8
git clone https://github.com/dotnet/dotnet .
./prep.sh && ./build.sh --online
mkdir -p $HOME/.dotnet
tar -zxf artifacts/x64/Release/dotnet-sdk-9.0.100-centos.8-x64.tar.gz -C $HOME/.dotnet
ln -s $HOME/.dotnet/dotnet /usr/bin/dotnet

Codespaces

You can also utilize GitHub Codespaces where you can find preset containers in this repository.

Building from released sources

You can also build from sources (and not from a context of a git repository), such as the ones you can acquire from a dotnet/dotnet release. In this case, you need to provide additional information which includes the original repository and commit hash the code was built from so that the SDK can provide a better debugging experience (think the Step into.. functionality). Usually, this means the dotnet/dotnet repository together with the commit the release tag is connected to.

In practice, this means that when calling the main build script, you need to provide additional arguments when building outside of a context of a git repository.
Alternatively, you can also provide a manifest file where this information can be read from. This file (release.json) can be found attached with the dotnet/dotnet release.

Synchronizing code into the VMR

Sometimes you want to make a change in a repository and test that change in the VMR. You could of course make the change in the VMR directly (locally, as the VMR is read-only for now) but in case it's already available in your repository, you can synchronize it into the VMR (again locally).

To do this, you can start a dotnet/dotnet Codespace. You will see instructions right when the Codespace starts. Alternatively, you can clone the repository locally and use the [eng/vmr-sync.sh](../../eng/vmr-sync.sh) script to do that. Please refer to the documentation in the script for more details.

List of components

To enable full offline source-building of the VMR, we have no other choice than to synchronize all the necessary code into the VMR. This also includes any code referenced via git submodules. More details on why and how this is done can be found here:

Strategy for managing external source dependencies
Source Synchronization Process

Detailed list

src/arcade
dotnet/arcade@0f16479
src/aspnetcore
dotnet/aspnetcore@362cdcd
- src/aspnetcore/src/submodules/googletest
  google/googletest@b10fad3
- src/aspnetcore/src/submodules/MessagePack-CSharp
  aspnet/MessagePack-CSharp@ecc4e18
src/cecil
dotnet/cecil@45dd3a7
src/command-line-api
dotnet/command-line-api@02fe27c
src/deployment-tools
dotnet/deployment-tools@1d17426
src/diagnostics
dotnet/diagnostics@5ce78f6
src/emsdk
dotnet/emsdk@ee8c41a
src/format
dotnet/format@ae20800
src/fsharp
dotnet/fsharp@341b2fb
src/installer
dotnet/installer@5d396b5
src/msbuild
dotnet/msbuild@c8b80b9
src/nuget-client
nuget/nuget.client@19d1a11
- src/nuget-client/submodules/NuGet.Build.Localization
  NuGet/NuGet.Build.Localization@f15db7b
src/razor
dotnet/razor@1d591be
src/roslyn
dotnet/roslyn@1f80211
src/roslyn-analyzers
dotnet/roslyn-analyzers@b924542
src/runtime
dotnet/runtime@7990c07
src/scenario-tests
dotnet/scenario-tests@8af694a
src/sdk
dotnet/sdk@6c6a5a5
src/source-build-externals
dotnet/source-build-externals@283f1ea
- src/source-build-externals/src/abstractions-xunit
  xunit/abstractions.xunit@b75d54d
- src/source-build-externals/src/application-insights
  Microsoft/ApplicationInsights-dotnet@5e2e7dd
- src/source-build-externals/src/azure-activedirectory-identitymodel-extensions-for-dotnet
  AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet@bb354ce
- src/source-build-externals/src/cssparser
  dotnet/cssparser@0d59611
- src/source-build-externals/src/docker-creds-provider
  mthalman/docker-creds-provider@5701f66
- src/source-build-externals/src/humanizer
  Humanizr/Humanizer@3ebc38d
- src/source-build-externals/src/MSBuildLocator
  microsoft/MSBuildLocator@e0281df
- src/source-build-externals/src/newtonsoft-json
  JamesNK/Newtonsoft.Json@0a2e291
- src/source-build-externals/src/xunit
  xunit/xunit@f110e5b
- src/source-build-externals/src/xunit/src/xunit.assert/Asserts
  xunit/assert.xunit@5c8c10e
- src/source-build-externals/src/xunit/tools/build
  xunit/build-tools@8e186b0
- src/source-build-externals/src/xunit/tools/media
  xunit/media@5738b6e
src/source-build-reference-packages
dotnet/source-build-reference-packages@b5ceed9
src/sourcelink
dotnet/sourcelink@e2f4720
src/symreader
dotnet/symreader@2c8079e
src/templating
dotnet/templating@97b0da7
src/test-templates
dotnet/test-templates@e1aecaf
src/vstest
microsoft/vstest@b397a1f
src/windowsdesktop
dotnet/windowsdesktop@9c427e2
src/winforms
dotnet/winforms@6d97d79
src/wpf
dotnet/wpf@84706a5
src/xdt
dotnet/xdt@9a1c3e1
src/xliff-tasks
dotnet/xliff-tasks@194f328

The repository also contains a JSON manifest listing all components in a machine-readable format.

Filing Issues

This repo does not accept issues as of now. Please file issues to the appropriate development repos. For issues with the VMR itself, please use the source-build repository.

Useful Links

Design documentation for the VMR - a set of documents describing the high-level design and the why's and how's
.NET Source-Build
What is .NET

.NET Foundation

.NET Runtime is a .NET Foundation project.

License

.NET is licensed under the MIT license.

License

radical/dotnet

ErrorLooks like something went wrong!

About

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Error
Looks like something went wrong!

Packages