.NET Core - 通过 .NET Core 将 .NET 迁移到跨平台
.NET Core - 通过 .NET Core 将 .NET 迁移到跨平台
Phillip Carter | April 2016
微软正在将 .NET Core 构建为 .NET 的新实现。 此 .NET Core 使开发人员能够为云优化的工作负载编写跨平台代码。 尽管许多开发人员对开源开发表示欢迎，但 .NET Core 的出现有什么特别的意义呢？ 因此，本文将介绍 .NET Core 的现状及其目标、.NET Core 与 Microsoft .NET Framework 之间的关系以及可用于启动 .NET Core 的命令行工具的基本知识。
什么是 .NET Core？
要理解 .NET Core，了解 .NET 本身非常重要。 许多开发人员使用 ". NET，但不仅仅是.NET，是包含各种实现的ECMA标准。 这些实现包括 .NET Framework、Mono 和 Unity，以及 .NET Core。 这意味着 .NET Framework 和 .NET Core 共享许多体验。 但是，.NET Core 是一种基于几个不同原则的新实现。
首先，.NET Core 是跨平台的。 适用于多个版本的 Windows、OS X 和 Linux。 它支持各种 CPU 体系结构。 Microsoft 正在增加其支持的 Linux 发行版和 CPU 体系结构，其最终目标是在尽可能多的位置运行 .NET Core。
同时，.NET Core 在设计和体系结构方面从根本上是模块化结构。 运行时、库和编译器等组件都是通过设计正确的接口进行交互的单独实体。 因此，您可以根据特定需求"更换"组件。 库本身也是模块化的，通过 NuGet 分发。 因此，您可以只将库限制为所需的库，并微调 .NET Core 占用空间以适应您的系统。
此外，为 .NET Core 编写的代码是可移植的，可以调整为在各种支持的平台上运行。 根据项目的目标，.NET Core 代码可以运行在 .NET Framework、Mono 和 Xamarin 平台以及 Windows 8、Windows Phone 和通用 Windows 平台 （UWP） 中。 有关详细信息，请参阅 .NET平台标准 bit.ly/1Of6W1r 和英语）。
最后，.NET Core 的成本比您花费的要高，因此成本效益更高。.NET Core 工作的目标之一是帮助开发人员清楚地了解抽象的成本。 因此，我们实施的模型成本仅与我们使用的模型相同，并且我们使用高水平的抽象来解决问题，从而明确所需的成本。 抽象不能免费实现。 并且，您不该向开发人员隐藏成本。 此外，.NET Core 优先考虑标准库的性能，以尽量减少内存分配和系统中的内存占用。
.NET Core 方案
目前有四种方案可以为 .NET Core 编写代码。 有四 ASP.NET：跨平台应用程序、Web 应用、跨平台控制台应用、跨平台库和框架以及 UWP。
以速度为中心构建的 ASP.NET Core 1.0 是 .NET Core 的跨平台 Web 堆栈。 现在，您可以执行以前 ASP.NET 操作，例如将 Web 应用部署到 Linux 上的容器中。 ASP.NET 核心提供的功能范围 bit.ly/1TqPcIo请参阅功能。
跨平台控制台应用的范围比许多开发人员想象的要大得多。 例如 ASP.NET 核心 Web 应用是控制台应用，它读取信息并写入端口。 构成整个系统后端的一组微服务也可以描述为控制台应用。
跨平台库和框架之间的区别只有一个标准。 库是基于 .NET Core 构建的最自然的候选项之一。 但是，随着标准范围的扩大，分布式计算框架也是一个很好的候选者。
最后，针对 Windows 10 设备系列的 UWP 应用在 .NET Core 上运行。 您可以包括 .NET Core 库来生成丰富的 Windows 10 应用，并生成功能齐全的 UWP 应用。
这意味着，目前有许多内容可以为 .NET Core 创建。 随着工具的成熟和扩展，您可以构建的内容将会增加。
如果您拥有适用于这四种方案之一的 .NET Framework 资产，或者要体验新技术，则可以参考bit.ly/1Q1Q18q开始编写 .NET Core 代码。
.NET Core 和 .NET Framework 的比较
大多数开发人员都知道和熟悉的 .NET 是 .NET Framework。 那么，.NET Core 和 .NET Framework 之间的区别是什么？ 要记住的第一个步骤是使用相同的语言 （C#、F# 和 Visual Basic） 编写所有代码。 编写代码的体验始终具有熟悉的外观。 但是，.NET Core 是新堆栈，不是 .NET Framework 的子集，因此将 .NET Core 和 .NET Framework 视为两个共同演变的相同堆栈是合适的。
.NET Framework 是用于为 Windows 7 到 Windows 10 创建桌面应用程序的堆栈，并且将来不会更改。 事实上，.NET Framework 和 .NET Core 代码可以共存，而不会在同一解决方案中相互影响。 例如，考虑使用在 .NET Framework GUI（Windows 窗体）中创建的服务的方案。
在考虑 .NET Core 和 .NET Framework 的共同点和差异时，从 API 表面区域和运行时功能两个角度看，它们更易于理解。 图 1显示两个平台上的重复 API。
图 1 .NET Framework 和 .NET Core 共有的 API 子集
.NET Core 和 .NET Framework 都有实现的 .NET API（尽管基础实现可能不同）。 同时，.NET Core 和 .NET Framework 都有自己的 API 和功能，而另一个 API 和功能则不相同。 例如，.NET Framework 中存在多个 GUI 框架和特定于 Windows 的 API，这些 API 在 .NET Core 中不存在。 同样，.NET Core 具有 .NET Framework 中所没有的跨平台功能和 API。
此外，.NET Framework 是 Windows 更新所针对的 Windows 组件。 但是，.NET Core 使用完全不同的模型来提供正常运行位置和服务。.NET Core 由 NuGet 包组成，并具有在应用本地安装的运行时。 这意味着应用以"包括"的方式分发 .NET Core，因此您可以与计算机或设备上的其他 .NET Core 实例并行运行。 因此，.Net Core 更新服务由包管理器按应用完成，而不是由操作系统更新全局执行。
实际问题是，如果我为一个堆栈编写代码，我是否能够在另一个堆栈上运行它？ 任何问题都会给出类似的答案，但在某些情况下，这是一个答案。 如果要使用的 API 在两个平台上实现，则相对容易调整代码以在 .NET Core 和 .NET Framework 上运行。 但是，不能在两个堆栈上运行依赖于执行环境的代码，也无法同时运行使用一个堆栈不支持的 API 的代码（例如，使用基于 XAML 的 UI 的库）。 .NET Portability Analyzer 可以用作命令行工具（bit.ly/1Sd8oIK、VisualStudio 扩展（bit.ly/1LqX0aF、英语），分析 .dll 文件并生成一个报告，显示代码从 .NET Framework 移植到 .NET Core 的程度。 将来将发布更多有助于移植的工具。
コマンド ライン: .NET Core のエントリ ポイント
.NET Core には、アプリ開発に使用する基本ツールセットが付属し、新たなツールや強化されたツールが用意されています。このツールセットを、.NET Core CLI (.NET Core コマンドライン インターフェイス) と呼びます。.NET Core の他の部分と同様、.NET Core CLI もオープン ソース (GitHub.com/dotnet/cli、英語) で、開発作業に密接に関係するオープン ソース コミュニティの運営が活発に行われています。
引入新工具集的原因有很多。 首先，您需要支持 .NET Core 涵盖的所有平台的关键开发方案。 可能有很多不同的平台集，但任何平台的开发人员都了解命令行体验作为基础。 换句话说，命令行默认内置于各种平台上。
扩展逻辑时，考虑在整个支持的平台上支持相同的 UX。 理想中，您可以在 Linux、Windows 和 OS X 之间移植 UX，并且不需要重新学习工具、每个平台的语法和语义。 命令行允许您在任何平台上使用相同的命令行。 使用模式保持不变，语法相同。
在多个平台上使用单个工具集的想法也适用于高级工具的 Visual Studio Code 和 Visual Studio。 这些高级工具基于 .NET CLI 进行分层，并计划利用这些分层方法为 .NET Core 项目提供未来支持。 这意味着，当您在 Visual Studio 中生成 .NET Core 应用时，将调用 .NET CLI 工具来运行生成。
尝试 .NET Core 命令行界面
要从 .NET Core CLI 开始，请按照入门 aka.ms/dotnetcoregs和英语入门指南。 简而言之，只需下载安装程序以适合您的平台（为 Ubuntu 注册新的 apt-get 源）并安装该工具，即可开始操作。 安装程序在所有支持的操作系统的系统 PATH 上设置安装文件夹，并设置 CLI 所需的所有其他环境变量。
然后，可以通过传递命令（也称为"谓词"）来调用驱动程序"dotnet"来启动它。 驱动程序负责在命令中传递参数和执行命令。 在撰写本文时，CLI 包中包含的命令如图 2所示。 当然，在本文发布之前，Microsoft 会添加生产力命令，这并不奇怪。
图 2 当前可用的常见 .NET CLI 命令
| 命令 | 描述 |
| dotnet new | 对语言使用 C# 初始化类库或控制台应用的有效项目。 |
| dotnet restore | 还原指定项目的项目.json 文件中定义的依赖项。 依赖项通常是应用使用的 NuGet 包。 |
| dotnet build | 生成代码。 此命令生成项目的中间语言 （IL） 二进制文件。 如果项目是控制台应用，则生成的输出是可立即运行的可执行文件。 默认情况下，build 命令将生成的程序集和可执行文件（如果适用）打印到调用该命令的目录的 bin 目录中。 |
| dotnet test | 优秀的工具总是可以运行测试。 此命令允许您使用 project.json 文件中指定的运行程序运行一组测试。 当前支持的测试运行程序是 xUnit 和 NUnit。 |
| dotnet publish | 发布应用以在目标计算机上运行。 |
| dotnet pack | pack 命令将项目打包到 NuGet 包中。 输出的 nupkg 文件系列通过上载到源或覆盖本地文件夹在还原操作中使用。 |
| dotnet run | 运行命令编译并运行应用。 此命令执行的操作与按CTRL_F5时执行的操作相同。 只与不使用 Visual Studio 不同。 |
除了包中包含的命令外，您还可以在 project.json 中将命令添加为工具以还原该命令。 这些命令打包在 NuGet 包中，提供易于使用且易于理解的扩展模型。
总结
您是否了解 .NET Core 并编写跨平台运行的 .NET 代码？ 新堆栈中的 .NET Core 提供了传统 .NET Framework 无法提供的有用功能。.NET CLI 还引入了出色的命令行体验，这些体验可以作为开发人员体验的基础，并集成到 Visual Studio 和 Visual Studio Code 等其他工具中。
最后，我们理解，开发人员有许多为 .NET Framework 创建的资产。 我们希望，随着 .NET Framework 的演变，这些资产将继续增长。 Microsoft 设想 .NET Framework 和 .NET Core 在利用两个堆栈优势的系统中共存。
对于可能了解和参与这种情况的人，我们将介绍一些起点。
- .NET Core Framework：GitHub.com/dotnet/coreclr
- .NET库：GitHub.com/dotnet/corefx
- 命令行界面和工具：GitHub.com/dotnet/cli
- Roslyn 编译器（C# 和 Visual Basic）和 Visual Studio语言工具：GitHub.com/dotnet/roslyn（英语）
- .NET Core文档：GitHub.com/dotnet/core-docs
微软正在处理许多其他 .NET 开源项目。 如果您对此类项目感兴趣，请参阅 .NET 基金会，这是一个独立组织，旨在发展与 .NET 相关的开放开发和协作。 Microsoft 与 Xamarin、Umbraco、Salesforce 和 .NET 社区一起为 .NET Foundation 提供了多个项目。有关 .NET Foundation 本身及其参与情况，请参阅dotNetFoundation.org/projects。
Surupa Biswas是 Microsoft .NET 团队的项目经理。 他热爱系统和编程语言理论，并一直与朋友讨论并发模型，直到深夜。 他希望有一天，任何系统的运行时行为都用类型系统来表达，人类可以进一步增强逻辑思维。 联系人[email protected]（仅英语）。
Zlatko Knezevic是微软 .NET 团队的项目经理 （PM）。 2005 年加入 Microsoft 后，他首先在 CEE 担任开发人员报告员，然后加入 SQL Server PM。 在那里，他参与了广泛的工作，从向核心引擎添加新索引到构建处理大数据和数据检测的高级服务。 自 2015 年加入 .NET 团队以来，他一为 .NET Core 提供跨平台体验。 联系人[email protected]（仅英语）。