Skip to content

Latest commit

 

History

History
365 lines (303 loc) · 30.8 KB

dogfooding.md

File metadata and controls

365 lines (303 loc) · 30.8 KB

Dogfooding nightly builds of .NET

This document provides the steps necessary to consume a nightly build of .NET runtime and SDK.

Obtaining nightly builds of NuGet packages

If you are only looking to get fixes for an individual NuGet package, and don't need a preview version of the entire runtime, you can add the nightly build package feed to your NuGet.config file. The easiest way to do this is by using the dotnet CLI:

(Recommended) Create a local NuGet.Config file for your solution, if don't already have one. Using a local NuGet.Config file will enable the nightly feed as a package source for projects in the current directory only.

dotnet new nugetconfig

Next, add the package source to NuGet.Config with the dotnet nuget add source command:

dotnet nuget add source -n dotnet6 https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet6/nuget/v3/index.json

Then, you will be able to add the latest prerelease version of the desired package to your project.

Example: To add version 6.0.0-alpha.1.20468.7 of the System.Data.OleDb package, use the dotnet add package command:

dotnet add package System.Data.OleDb -v 6.0.0-alpha.1.20468.7

To use nightly builds of the entire runtime, follow the steps given in the rest of this document instead.

Install prerequisites

  1. Acquire the latest nightly .NET SDK by downloading and extracting a zip/tarball or using an installer from the installers and binaries table in dotnet/installer (for example, https://aka.ms/dotnet/net6/dev/Sdk/dotnet-sdk-win-x64.zip).

  2. By default, the dotnet CLI will use the globally installed SDK if it matches the major/minor version you request and has a higher revision. To force it to use a locally installed SDK, you must set an environment variable DOTNET_MULTILEVEL_LOOKUP=0 in your shell. You can use dotnet --info to verify what version of the Shared Framework it is using.

  3. Reminder: if you are using a local copy of the dotnet CLI, take care that when you type dotnet you do not inadvertently pick up a different copy that you may have in your path. On Windows, for example, if you use a Command Prompt, a global copy may be in the path, so use the fully qualified path to your local dotnet (e.g. C:\dotnet\dotnet.exe). If you receive an error "error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0." then you may be executing an older dotnet.

After setting up dotnet you can verify you are using the dogfooding version by executing dotnet --info. Here is an example output at the time of writing:

>dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.100-alpha.1.20514.11
 Commit:    69ee2fdd13

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   c:\dotnet\sdk\6.0.100-alpha.1.20514.11\

Host (useful for support):
  Version: 6.0.0-alpha.1.20468.7
  Commit:  a820ca1c4f

.NET Core SDKs installed:
  6.0.100-alpha.1.20514.11 [c:\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 5.0.0-rc.2.20466.8 [c:\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.0-alpha.1.20468.7 [c:\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.0-rc.1.20417.4 [c:\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
  1. Our nightly builds are uploaded to dotnet-blob feeds, not NuGet - so ensure the .NET Core blob feed is in your nuget configuration in case you need other packages from .NET Core that aren't included in the download. For example, on Windows you could edit %userprofile%\appdata\roaming\nuget\nuget.config or on Linux edit ~/.nuget/NuGet/NuGet.Config to add these lines:
<packageSources>
    <add key="dotnet6" value="https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet6/nuget/v3/index.json" />
    <add key="gRPC repository" value="https://grpc.jfrog.io/grpc/api/nuget/v3/grpc-nuget-dev" />
    ...
</packageSources>

(Documentation for configuring feeds is here.)

Setup the project

  1. Create a new project

    • Create a new folder for your app and change to that folder
    • Create project file by running dotnet new console
  2. Restore packages so that you're ready to play:

$ dotnet restore

Consume the new build

$ dotnet run

Rinse and repeat!

Advanced Scenario - Using a nightly build of Microsoft.NETCore.App

When using the above instructions, your application will run against the same .NET runtime that comes with the SDK. That works fine to get up and running quickly. However, there are times when you need to use a nightly build of Microsoft.NETCore.App which hasn't made its way into the SDK yet. To enable this, there are two options you can take.

Option 1: Framework-dependent

This is the default case for applications - running against an installed .NET runtime.

  1. You still need to install the prerequisite .NET SDK from above.
  2. Optionally, install the specific .NET runtime you require globally or download get the latest one available from the nightly build table
  3. Modify your .csproj to reference the nightly build of Microsoft.NETCore.App
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <!-- Ensure that the target framework is correct e.g. 'net6.0' -->
    <TargetFramework>net6.0</TargetFramework>
    <!-- modify version in this line with one reported by `dotnet --info` under ".NET runtimes installed" -> Microsoft.NETCore.App -->
    <RuntimeFrameworkVersion>6.0.0-alpha.1.20468.7</RuntimeFrameworkVersion>
  </PropertyGroup>
$ dotnet restore
$ dotnet run

Option 2: Self-contained

In this case, the .NET runtime will be published along with your application.

  1. You still need to install the prerequisite .NET SDK from above.
  2. Modify your .csproj to reference the nightly build of Microsoft.NETCore.App and make it self-contained by adding a RuntimeIdentifier (RID).
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <!-- Ensure that the target framework is correct e.g. 'net6.0' -->
    <TargetFramework>net6.0</TargetFramework>
    <!-- modify build in this line with version reported by `dotnet --info` as above under ".NET runtimes installed" -> Microsoft.NETCore.App -->
    <!-- moreover, this can be any valid Microsoft.NETCore.App package version from https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json -->
    <RuntimeFrameworkVersion>6.0.0-alpha.1.20468.7</RuntimeFrameworkVersion>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier> <!-- RID to make it self-contained -->
  </PropertyGroup>
$ dotnet restore
$ dotnet publish
$ bin\Debug\net6.0\win-x64\publish\App.exe

Nightly builds table

Platform Main
Windows (x64)
Installer (Checksum)
zip (Checksum)
NetHost (zip)
Symbols (zip)
Windows (x86)
Installer (Checksum)
zip (Checksum)
NetHost (zip)
Symbols (zip)
Windows (arm64)
Installer (Checksum)
zip (Checksum)
NetHost (zip)
Symbols (zip)
macOS (x64)
Installer (Checksum)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
macOS (arm64)
Installer (Checksum)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
Linux (x64) (for glibc based OS)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
Linux (armhf) (for glibc based OS)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
Linux (arm64) (for glibc based OS)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
Linux-musl (x64)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
Linux-musl (arm)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
Linux-musl (arm64)
tar.gz (Checksum)
NetHost (tar.gz)
Symbols (tar.gz)
Dpkg Based Systems (x64)
Runtime-Deps (Checksum)
Host (Checksum)
App Hosts (Checksum)
Host FX Resolver (Checksum)
Targeting Pack (Checksum)
Shared Framework (Checksum)
CentOS 7 (x64)
Runtime-Deps (Checksum)
Host (Checksum)
App Hosts (Checksum)
Host FX Resolver (Checksum)
Targeting Pack (Checksum)
Shared Framework (Checksum)
RHEL 7.2 (x64)
Host (Checksum)
App Hosts (Checksum)
Host FX Resolver (Checksum)
Targeting Pack (Checksum)
Shared Framework (Checksum)
Fedora 27 (x64)
Runtime-Deps (Checksum)
Host (Checksum)
App Hosts (Checksum)
Host FX Resolver (Checksum)
Targeting Pack (Checksum)
Shared Framework (Checksum)
SLES 12 (x64)
Runtime-Deps (Checksum)
Host (Checksum)
App Hosts (Checksum)
Host FX Resolver (Checksum)
Targeting Pack (Checksum)
Shared Framework (Checksum)
OpenSUSE 42 (x64)
Runtime-Deps (Checksum)
Host (Checksum)
App Hosts (Checksum)
Host FX Resolver (Checksum)
Targeting Pack (Checksum)
Shared Framework (Checksum)

Note: Our Linux packages (.deb and .rpm) are put together slightly differently than the Windows and Mac specific installers. Instead of combining everything, we have separate component packages that depend on each other. If you're installing these directly from the installer files (via dpkg or similar), then you'll need to install them in the order presented above.