DNVM、DNX 和 DNU - 理解 ASP.NET 5 运行时选项
理解 .NET 版本管理器 (DNVM)、.NET 执行环境 (DNX) 和 .NET 开发工具 (DNU) 之间的关系对于使用 ASP.NET 5 进行开发至关重要。
ASP.NET 5 为 .NET 框架引入了一种新的运行时模型，该模型允许我们采用“按需付费”的方法，仅使用应用程序所需的框架组件来构建可组合应用程序，而无需依赖主机上存在的中央、单一库存储库。
这种新模型还为我们提供了命令行工具，用于在 Visual Studio 之外管理 .NET 版本选择、库包和执行环境。现在可以使用文本编辑器和命令行（Windows 上的 CMD 或 Powershell）开发跨平台 ASP.NET 应用程序，而无需打开 Visual Studio。
ImagebyCésar Astudillo | 保留部分权利
理解 .NET 版本管理器 (DNVM)、.NET 执行环境 (DNX) 和 .NET 开发工具 (DNU) 之间的关系对于使用 ASP.NET 5 进行开发至关重要。在这篇文章中，我们将介绍如何安装和使用 DNVM、DNX 和 DNU，以便从命令行使用 ASP.NET。
- 入门 - 安装 DNVM
- 使用 DNVM - 列出可用的 .NET 运行时
- 使用 DNVM - 安装 DNX 运行时版本
- DNVM 升级 VS. DNVM 安装
- 使用 DNVM - 选择或更改活动的 DNX 运行时
- 从 PATH 变量中删除运行时引用
- 使用别名使输入更容易
- DNX 和 DNU - 从命令行使用示例项目
- 使用 DNU Restore 恢复包
- 使用 DNX 运行示例应用程序
- 其他资源和感兴趣的项目
DNVM - .NET 版本管理器
DNVM 是一个命令行版本管理工具。顾名思义，DNVM 提供了配置 .NET 运行时所需的功能。我们可以使用 DNVM 在进程、用户或机器级别指定要使用的 .NET 执行环境版本。
DNX - .NET 执行环境
DNX 到底是什么？来自ASP.NET 文档网站：
.NET 执行环境 (DNX) 是一个软件开发工具包 (SDK) 和运行时环境，它包含了构建和运行适用于 Windows、Mac 和 Linux 的 .NET 应用程序所需的一切。它提供了一个宿主进程、CLR 宿主逻辑和托管入口点发现。DNX 是为运行跨平台 ASP.NET Web 应用程序而构建的，但它也可以运行其他类型的 .NET 应用程序，例如跨平台控制台应用程序。
广义地说，有不同的 DNX 运行时版本可用，这些版本反映了您希望在应用程序中使用哪个 .NET 框架版本。在基本级别上，有针对以下情况的不同版本：
- .NET Framework - 我们都熟悉和喜爱的 .NET 框架。
- .NET Core - .NET Framework 的一个子集，包含模块化运行时和库实现，并通过 Nuget 进行管理。.NET Core 是跨平台的、开源的，包含 CoreFX 中的核心库和 CoreCLR 中的核心运行时。
- Mono - 使用 Mono，我们可以创建在 OSX 和 Linux 机器上编译和运行的 ASP.NET 应用程序。
我们可以使用 .NET 版本管理器来选择要与应用程序一起使用的 DNX 版本。
DNU - .NET 开发工具
DNU 是一个命令行工具，它提供各种实用功能来协助 ASP.NET 开发。最常见的是，我们将使用 DNU 在应用程序中安装和管理库包，和/或打包和发布我们自己的应用程序。
DNU 在幕后使用 Nuget 进行包管理和部署。
入门 - 安装 DNVM
如果您安装了 Visual Studio 2015（目前可作为发布候选版本此处），则您已经安装了 .NET 版本管理器。
更新：根据 ASP.NET 团队的说法（感谢Glenn！），DNX/DNVM 实际上只有在安装 VS 2015 后运行“文件 -> 新建”时才会安装，因此，如果您安装了 VS 2015 但尚未打开新文件，则您的机器上还没有它。
如果您想升级到最新版本的 DNVM，或者您想使用 ASP.NET 但不想安装 Visual Studio，您可以从 Windows 命令提示符 (CMD) 或使用 Powershell 按如下方式下载 DNVM 脚本：
使用 CMD 安装或升级 DNVM
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "&{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}"
使用 Powershell 安装或升级 DNVM
&{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}
一旦我们的机器上有了 DNVM，我们应该能够启动 Windows 命令提示符并开始工作。
在命令行（或 Powershell 提示符）下运行以下命令，以查看 DNVM 实际上是否已安装在您的机器上：
不带参数运行 DNVM
> dnvm
如果到目前为止一切顺利，您应该会看到以下内容（为了简单起见，本文将使用 CMD）：
不带参数运行 DNVM 的控制台输出
现在我们已经安装并运行了 DNVM，让我们看看我们有哪些可用的 DNX 版本，以及如果需要如何安装 DNX 版本。
使用 DNVM - 列出可用的 .NET 运行时
要查看我们可用的运行时选项，我们可以从控制台运行以下命令：
使用 DNVM List 列出可用的 DNX 运行时
> dnvm list
我之前在我的机器上安装了 Visual Studio 2015，它也安装了一些 DNX 版本，所以当我运行上面的命令时，我看到以下输出：
DNVM List 的控制台输出
因为我已经安装了 Visual Studio 2015，所以有适用于 .NET Framework（上图中 beta4 clr）和 .NET Core（上图中 coreclr）的 32 位和 64 位架构的 DNX 版本。
如果您尚未安装 Visual Studio 2015，您的列表很可能是空的。安装 DNVM 本身并不会在您的机器上安装任何 DNX 版本。不用担心，我们接下来会解决这个问题。
使用 DNVM - 安装 DNX 运行时版本
如果您刚安装了全新的 DNVM，或者您想获取特定 DNX 实现的最新版本，我们可以使用带有适当参数的 dnvm install 命令：
默认情况下，DNVM 将使用基本的 .NET 框架，并假定 x86 架构。例如，如果我们执行以下操作：
DNVM 安装最新版本
> dnvm install latest
DNVM 将下载并安装适用于 x86 架构的常规 .NET 框架的最新稳定版本。如果我们再次运行 dnvm list，我们会看到以下内容：
运行 DNVM 安装最新版本后安装的 DNX 运行时
如果我们想指定不同的运行时（例如，CoreCLR 而不是 .NET Framework，和/或指定 x64 版本），我们需要添加-r ( -运行时）和/或-架构 ( -架构）标志和值
为特定运行时/架构安装最新的 DNVM
> dnvm install latest -r coreclr -arch x64
一旦上述操作完成，我们现在已将适用于 x86 架构的完整 .NET Framework 的最新版本和适用于 x64 架构的 CoreCLR 添加到我们的可用运行时列表中
已安装的 DNX 运行时
DNVM 升级 VS. DNVM 安装
DNVM 还有一个升级命令，它的行为与Install.
DNVM Install 获取指定版本，并通过将其添加到进程 PATH 变量中，使其在当前 Command 进程中处于活动状态。此“活动”选择仅在我们的终端会话期间有效。一旦当前终端会话关闭，活动选择将恢复为无，或者恢复为之前在用户 PATH 变量中作为默认值保留的任何值。
DNVM Upgrade 本质上执行相同的操作，但也会将其添加到用户的 PATH 变量中作为默认活动版本，并更新默认别名。例如，如果我们使用dnvm 升级安装最新 64 位版本的 .NET 框架 clr
使用 DNVM Upgrade 将 .NET Framework CLR 升级到最新版本
> dnvm upgrade -r clr -arch x64
运行上述命令后，我们的控制台输出告诉我们最新版本的dnx-clr-win-x64不仅已添加到当前进程 PATH，而且已添加到我们的用户 PATH。此外，“default”别名已更新为指向刚安装的版本
DNVM Upgrade 的控制台输出
请注意dnvm 升级从 Nuget 拉取最新的*稳定*版本。如果您想使用最新的*不稳定*（开发）版本，可以使用
升级到最新的不稳定（开发）运行时版本
> dnvm upgrade -u
在上面，您可以像以前一样使用 -r 和 -arch 标志指定运行时/架构。
2015/5/17 - 注意：如果您安装了 Visual Studio 2015，系统环境变量 PATH 很可能指向 C:\Program Files\Microsoft DNX\Dnvm\。截至本文撰写之时，Visual Studio 版本的 DNVM 不识别 -u (-unstable) 标志。即使您在本文章开头使用 shell 脚本安装了 DNVM，也会首先找到 Visual Studio 变量。要使用 -u 标志，您需要更改 PATH 变量的顺序，或者删除 Visual Studio PATH 并使用上述脚本之一添加 DNVM。
使用 DNVM - 选择或更改活动的 DNX 运行时
请注意，在上一节中，一旦我们开始安装新的 DNX 运行时版本，控制台输出的“Active”列中就会出现星号。当我们使用dnvm 安装，DNVM 会将刚刚安装的版本设置为当前进程的默认活动版本（换句话说，仅适用于当前终端会话）。
如前所述，当我们运行 dnvm upgrade 时，DNVM 会将刚刚安装的版本设置为默认活动版本，不仅适用于当前进程，而且适用于用户级别。
我们可以使用以下命令切换到不同的 DNX 运行时：dnvm use默认情况下，dnvm use更改当前命令进程的活动选择。例如，给定上一节控制台输出中的当前活动运行时 (1.0.0-beta4-11566 clr x64)，我们可以决定在当前终端会话中切换到最新的 64 位 coreclr 版本
为当前进程选择或切换到不同的运行时
> dnvm use 1.0.0-beta4-11566 -r coreclr -arch x64
如果我们运行上述命令，然后再次运行dnvm list，我们会看到我们的活动版本已更改
为当前进程选择新的活动 DNX 运行时
但是，如果我们仔细查看上面的控制台输出，我们会看到新版本已添加到进程 PATH，这意味着，此选择仅在当前控制台进程中持续。如果我们关闭控制台窗口并打开另一个窗口，则将再次选择在我们的用户 PATH 中设置的默认值。
如果我们想设置我们的用户默认值，我们可以像之前一样运行命令，但我们可以添加-p ( -持久性）标志，这将导致选择添加到我们的用户路径而不是进程路径
为用户 PATH 选择或切换新的 DNX 运行时默认值
> dnvm use 1.0.0-beta4-11566 -r coreclr -arch x64 -p
现在，我们的选择将作为默认值在命令会话之间持续。我们仍然可以像以前一样为每个进程选择不同的版本，但除非我们进行额外更改，否则命令会话中的默认活动 DNX 运行时将是构建 11566 的 beta 4 CoreCLR。
从 PATH 变量中删除运行时引用
如果我们想从进程路径中删除所有运行时引用（换句话说，恢复到没有运行时设置为“活动”的状态），我们可以运行
从进程 PATH 变量中删除 DNX 运行时引用
> dnvm use none
如果我们想删除在用户 PATH 变量中设置的任何默认值，我们可以添加 -p 标志
从用户 PATH 变量中删除 DNX 运行时引用
> dnvm use none -p
使用别名使输入更容易
如果您一直按照示例进行操作，您可能会注意到每次要引用运行时版本时都键入完整的语义版本名称是多么痛苦。DNVM 允许我们为不同的已安装版本分配别名。我们可以在安装或升级时使用-a ( -别名）标志，或者我们可以使用别名命令。
例如，我们已经有一个别名，默认，在我的例子中，它是在我安装 Visual Studio 时设置的。它最初分配给常规的 x86 .NET 框架 CLR，然后在我们运行dnvm 升级在上一节中。截至目前，别名默认在我的机器上指向最新（构建 11566）x64 位版本的 .NET CLR。
我可以为最新 x64 版本的 CoreCLR 设置一个别名，如下所示：
为 DNX 运行时分配别名
> dnvm alias core-64-latest 1.0.0-beta4-11566 -r coreclr -arch x64
这样做之后，我就可以通过其别名引用该特定运行时，例如：
使用别名选择或切换到新的 DNX 运行时
> dnvm use core-64-latest
2015/5/17 - 注意：目前存在一个错误（请参阅 issue #175 / PR #248，位于 Github 上的 DNVM 仓库），即通过别名引用 CoreClr 运行时不起作用。截至本文撰写之时，PR 尚未合并，但本应按此处所述工作。在问题解决之前，仍然需要通过其完整版本名称引用任何 CoreClr 运行时……
我们可以通过简单地使用dnvm 别名命令，并将别名分配给不同的 DNX 运行时。
DNX 和 DNU - 从命令行使用示例项目
为了了解 DNVM、DNU 和 DNX 如何协同工作，我们将构建一个非常基本的示例项目，仅使用 Windows 命令提示符和文本编辑器（对于本文，我将使用 Sublime Text 3，但我们也可以轻松使用 Visual Studio Code 或记事本）。
首先，让我们创建一个项目目录，然后用 Sublime Text 打开该文件夹
使用 CMD 创建项目目录并导航到该目录
C:\Users\John> mkdir dnx_demo C:\Users\John> cd dnx_demo
然后，在 Sublime Text 中打开目录文件夹。首先，我们将添加一个 project.json 文件。
添加 project.json 文件
{
"version": "1.0.0-*",
"description": "Silly demo project",
"commands": {
"runme": "dnx_demo"
},
"frameworks": {
"dnx451": { },
"dnxcore50": {
"dependencies": {
"System.Console": "4.0.0-beta-22816",
"Microsoft.CSharp": "4.0.0-beta-22816"
}
}
}
}
在上面，请注意我们定义了一个命令“runme”，它指向项目名称。我们可以从命令行使用 dnx 调用此命令来运行我们的项目。另请注意，我们已将传统的 .NET Framework (dnx451) 和 .NET Core (dnxcore50) 都指定为编译目标，因此我们的应用程序将为这两种 DNX 运行时和框架进行交叉编译。
接下来，添加一个名为 Program.cs 的文件，并粘贴以下代码：
Program.cs 文件
using System;
namespace dnx_demo
{
public class Program
{
public void Main(string[] args)
{
Console.WriteLine("No Visual Studio Here!!");
Console.Read();
}
}
}
通过简单地添加这两个文件，我们（几乎）拥有运行一个非常基本但完整的 .NET 控制台应用程序所需的一切。保存上述两个文件，然后返回命令提示符。
使用 DNU Restore 恢复包
我们的 project.json 文件指定了项目所需的 Target Framework 和依赖项。请注意，对于此项目，当我们针对标准 .NET framework 4.5.1 运行时，不需要下载任何包——所需的引用已存在于 .NET framework 本身中。
在针对 .NET Core 框架和 CoreCLR 运行之前，我们需要恢复包。请记住，.NET Core 的核心思想是“按需付费”。换句话说，我们只拉取应用程序运行所需的库，而忽略其他所有内容。
我们可以通过简单地运行以下命令来恢复库包：dnu restore在我们的项目目录中
使用 DNU Restore 恢复库包依赖项
C:\Users\John\dnx_demo> dnu restore
使用 DNX 运行示例应用程序
恢复了包依赖项后，我们可以使用 DNX 运行应用程序。现在我们可以运行应用程序了，在选择要使用的 DNX 运行时之后。
在我的例子中，我们在前面的示例中将默认活动运行时设置为最新的 .NET Core CLR / x64，所以我们可以直接从项目目录中运行应用程序
使用 DNX 运行示例应用程序
C:\Users\John\dnx_demo> dnx . runme
仔细看看那里。由于我已经在项目目录中，我可以简单地输入 dnx，并使用句点表示当前目录。DNX 将解析我们在 project.json 文件中设置的命令 runme，并用它来运行项目。
我们也可以简单地通过名称引用项目
通过引用项目目录名称运行示例
C:\Users\John\dnx_demo> dnx . dnx_demo
或者，只要我们在项目目录中，我们就可以保持 REAL SIMPLE，只使用dnx . run
使用 dnx . run 运行示例
C:\Users\John\dnx_demo> dnx . run
现在，让我们将运行时从 .NET Core 切换到传统的 .NET Framework。回想一下，我们之前曾使用 dnvm upgrade 安装 .NET Framework 的最新 x64 二进制文件，并且当我们这样做时，我们的默认别名被分配给该运行时
使用 DNVM Use 切换到 .NET Framework 运行时
C:\Users\John\dnx_demo> dnvm use default
我们可以检查以确保我们现在正在针对 .NET CLR 而不是 CoreCLR，然后再次运行我们的应用程序
使用 .NET Framework 和标准 CLR 运行示例
总结
到目前为止，我们已经研究了使用 .NET 版本管理器、.NET 开发实用工具 (DNU) 和 .NET 执行环境的基础知识，以便在新 ASP.NET 环境中启动并运行基本应用程序。
在上面的简单示例中，我们在内存中编译并执行了项目。作为 dnx 运行过程的一部分，没有生成二进制文件。DNX 和 DNU 提供了丰富的附加功能，例如作为构建过程的一部分输出二进制文件（dnu build）、创建 Nuget 包（dnu pack）以及其他有用的命令。
DNU、DNX 和 DNVM 目前正在积极开发中，并且每天都在变化。请密切关注 ASP.NET 5 仓库，并在此处和其他地方留意更新。
我们将在接下来的文章中探索更多内容
其他资源和感兴趣的项目
- ASP.NET 5 文档网站（开发中）
- ASP.NET 版本管理器 Wiki
- Scott Gu 的 ASP.NET 5 公告
- ASP.NET：理解 OWIN、Katana 和中间件管道
- ASP.NET Web API 和 Identity 2.0 - 自定义 Identity 模型和实现基于角色的授权
- ASP.NET MVC 和 Identity 2.0：了解基础知识