Interpreting ASP.NET 5 & MVC6 Series (4): Core Technology and Environment Configuration

asp.net 5 is the next generation of asp.net. This version has been completely rewritten to be cross-platform. In the new version, Microsoft introduced the following tools and commands: DNVM, DNX, and DNU.

DNVM (.NET Version Manager): In order to implement a cross-platform directory, Microsoft provides the DNVM function. DNVM is the *** layer of ASP.NET. It is a set of Powershell scripts used to start the specified version of the ASP.NET runtime environment. It can manage various versions of the ASP.NET runtime environment (DNX) and perform corresponding upgrade operations by using the Nuget tool at the same time on the same machine.

DNX (.NET Execution Environment): DNX is the runtime environment of ASP.NET programs, used to start and run ASP.NET programs. The runtime environment includes the compilation system, SDK toolset, and Native CLR host environment. You can use DNVM to manage various versions of DNX. For example, the dnvm list command can list all available DNX environments, and dnvm install 0.1-alpha-build-0446 can install the specified version of DNX to the .dnx folder. You can find all installed versions of DNX in the %USERPROFILE%\.dnx\runtimes directory. Different operating systems have different DNX versions.

dnx.exe: dnx.exe is a command-line tool used to start a self-hosting environment. When using command-line code to start a program in a self-hosting environment, dnx is responsible for finding and calling the CLR Native Host. The dnx command is the entry point of the entire runtime environment. You can use dnx run to start the program.

dnu (DNX Utility): is a command-line package manager included in DNX. So as long as DNX is installed, you can use the dnu command. It can be used to restore packages, install packages, deploy packages, etc. For example, it can automatically download the custom assembly in project.json for use.

DNX architecture and operating principle

DNX is the core of ASP.NET program operation and follows the following two principles:

DNX should be self-contained. DNX can only know which Core CLR package to use after parsing the application dependency tree. Therefore, before getting the parsed tree, DNX cannot load any CLR, except the Roslyn compiler.

Dependency Injection (DI) runs through the entire system stack. DI is a core part of DNX, and all class libraries on DNX are built on DI.

The layered architecture of the DNX execution environment is as follows:

Layer 0: Native Process

The function of this layer is very simple. It is mainly used to find and call the CLR Native Host in Layer 1, and pass system-related parameters to the native host for subsequent use. Currently, DNX.exe is used in Windows to handle this matter, and IIS also provides an intermediary (AspNet.Loader.dll is provided in the bin directory of the website) to forward requests to the Native Host; Linux and Mac support this function through their corresponding versions of dnx.

DNX usage:

 dnx.exe --lib {paths} --appbase {path} [ProgramName]

--lib {paths}: The storage address of the assembly dll (usually the referenced third-party assembly and the project precompiled assembly). This address is where the managed code entry point of Layer 2 can load the assembly.

--appbase {path}: The directory where the program is saved. The default value is %CD%.

[ProgramName]: The name of the program. The assembly (or dll containing Programe::Main) where the program is located is saved in the --lib path. The default value is the name in appbase\project.json. In most cases, this name is the program host (Microsoft.Net.ApplicationHost) that contains the load chain. However, if your program contains an entry point (Main method) and is compiled into the --lib directory, you can use the name of the assembly as [ProgramName], which will completely ignore the load chain and start your program directly.

Layer 1: CLR Native Host

The content of this layer depends on the CLR version you choose. This layer has two responsibilities:

Start the CLR, which CLR you start depends on the CLR version you choose. If it is Core CLR, this layer will load coreclr.dll, configure and start the runtime environment, and then create an application domain (AppDomain) to run all managed code.

Call the entry point of the managed code (Layer 2). Once the entry point of the Native Host returns to the thread, the CLR thread will be cleaned up and closed, for example, the application domain (AppDomain) will be unloaded and the running environment will be stopped.

Layer 2: Managed Entry Point

Layer 2 (managed code entry) is the first layer for writing managed code, and its responsibilities are as follows:

Create a LoaderContainer (which contains the required ILoaders), which is responsible for loading assemblies based on their names. If the CLR needs an assembly, the LoaderContainer will use its ILoader to resolve the required assembly.

Use the root ILoader to load assemblies from the --lib path directory and resolve their dependencies.

Calls the main entry point of the program.

Layer 3: Application host/Application

If the developer compiles the entire program into an assembly and places it in the libpath directory, then this layer is your application. When using it, just pass the assembly name containing the program entry point as the parameter of [ProgramName], and Layer 2 will directly call the assembly.

However, in other cases, an application host is used to resolve the program's dependencies and start the program. Microsoft.Net.ApplicationHost is the application host provided by the runtime environment and has the following responsibilities:

Parse various dependent assemblies defined in project.json.

Add an ILoader to the LoaderContainer to load the corresponding assembly from various places (such as source code, NuGet, Roslyn, etc.).

Call the assembly's entry point, passing it as the next parameter to DNX.exe.

Layer 4: Application

This layer is the program developed by the developer, which runs on the application host.

Environment configuration:

To configure DNX, the operating environment of ASP.NET 5 programs, you first need to install and configure DNVM. The installation of DNVM is slightly different for different operating systems. We will briefly explain it here.

Windows installation command:

// Need to install PowerShell 3.0
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/master/dnvminstall.ps1'))"

Linux:

 curl -sSL https: //raw.githubusercontent.com/aspnet/Home/master/dnvminstall.sh | sh && source ~/.dnx/dnvm/dnvm.sh  

Mac OS X:

On Mac, you must first install the Mac system's own package manager Homebrew (http://brew.sh), and use the brew tap aspnet/k command to specify the ASP.NET5-related git repository, such as executing the following command:

 brew install dnvm

This command will automatically download the latest DNX from ttps://www.nuget.org/api/v2. After downloading, if your system does not recognize dnvm, you need to execute the following statement:

 source dnvm.sh

After the above DNVM is installed, the system will copy the dnvm file to the C:\Program Files\Microsoft DNX\Dnvm directory, and add the C:\Program Files\Microsoft DNX\Dnvm directory to the environment variable so that it can be used globally. Note: Only DNVM is installed here, and no version of DNX is installed. To install DNX, you can run dnvm or dnvm help to find the relevant commands. The specific commands are as follows:

 dnvm upgrade [-x86][-x64] [-svr50][-svrc50] [-g|-global] [-proxy
 ]

1. Install the latest version of DNX from the feed source

2. Set a default alias for the installed DNX

3. Add DNX bin to the user PATH environment variable

4.-g|-global Install globally (other users can also use it)

5.-f|-force Force update to *** version (even if *** version has been installed)

6.-proxy Use a specific address as a proxy when accessing a remote server

 dnvm install |||latest [-x86][-x64] [-svr50][-svrc50] [-a|-alias] [-g|-global] [-f|-force]

1. Install the specified DNX from the feed source

2. Install the specified DNX from the local file system

3.latest Install the latest version of DNX from the feed source

4. Add DNX bin to the path environment variable of the current command line

5.-p|-persistent Add DNX bin to the system PATH environment variable

6.-a|-alias Set an alias for the specified installed DNX

7.-g|-global Install globally

8.-f|-force Force installation of the specified DNX (even if the version has already been installed)

 dnvm use ||none [-x86][-x64] [-svr50][-svrc50] [-p|-persistent] [-g|-global]

1. Add DNX bin to the path environment variable of the current command line

2.none removes DNX bin from the path environment variable of the current command line

3.-p|-persistent Add DNX bin to the system PATH environment variable

4. -g|-global combined with -p to change the user PATH to the system PATH

dnvm list //List all installed DNX versions dnvm alias //List all DNX versions with aliases defined dnvm alias //Display the DNX names with aliases defined dnvm alias [-x86][-x64] [-svr50][-svrc50] //Set an alias for the specified DNX version

Dnu command and feed source configuration for managing assemblies

When managing packages through the dnu command, the following commands are usually used:

dnu restore: Queries all dependent packages of the program and downloads them all to the packages directory. This command downloads the entire dependent package and other dependent packages that these dependent packages depend on.

dun install: The install command is used to download the specified package and add it to the program.

dun publish: This command will package your program into a self-contained directory that can be run. It will create the following directory structure:

 output/
 output/packages
 outpot/appName
 output/commandName.cmd

1.The packages directory contains all the packages required by the application.

2. The appName directory contains the code of all applications. If other projects are referenced, the other referenced projects will also create directories at the same level as their own projects, that is, the generated directories will be at the same level as AppName.

3. The publish command will generate corresponding command line files for various commands in the commands node in project.json. For example, the web command in commands can be run through dnx web (format: dnx ).

Since dnu uses Nuget commands internally to manage packages, you need to correctly configure the Nuget feed source when using it. Currently, ASP.NET 5 related packages are all on myget feed, so we need to add this feed to run normally. These configuration information are managed in the %AppData%\NuGet\NuGet.config file under Windows (or ~/.config/NuGet/NuGet.config used by Mono under *nix). The following is an example:

 <? xml   version = "1.0"   encoding = "utf-8" ?>  
 < configuration >  
 < packageSources >  
 < add   key = "AspNetVNext"   value = "https://www.myget.org/F/aspnetvnext/api/v2/"   />  
 < add   key = "nuget.org"   value = "https://www.nuget.org/api/v2/"   />  
 </packageSources>​​  
 < disabledPackageSources   />  
 < activePackageSource >  
 < add   key = "nuget.org"   value = "https://www.nuget.org/api/v2/"   />  
 </activePackageSource>​​  
 </ configuration >  

In VS2015, you can set it directly through Tools--> Options--> Nuget Package Manager--> Package Sources, as shown in the following figure:

Also note that the above feed address is the daily build version of asp.net5. If you want to use a stable milestone version (such as 1.0.0_alpha4), you need to use the following address https://www.myget.org/F/aspnetmaster/api/v2/. Web Server Support

Microsoft provides several web server supports when implementing DNX, as follows:

 Microsoft.AspNet.Loader.IIS (Helios)

The server is used to load ASP.NET5 programs on IIS so as to integrate with the IIS process. It bypasses System.Web to improve performance and supports Windows authentication, static file access, etc. Its principle is to build a bridge between IIS and NDX.

 Microsoft.AspNet.Server.WebListener (WebListener)

The server loads programs, services, work roles, etc. outside of IIS through Microsoft.AspNet.Hosting. It runs directly on the Http.Sys core driver, consumes only a small amount of performance, and can benefit from port sharing, Windows authentication and other functions.

 Microsoft.AspNet.Server.Kestrel (Kestrel)

The server is loaded and run outside of IIS through Microsoft.AspNet.Server.Kestrel, and is designed to be used for cross-platform web services (Windows, Mac, Linux, etc.).