原文地址：blog.magnusmontin.net/2018/12/15/…
发布时间：2018年12月15日
微软在5月份的Build 2018上宣布，他们将把.NET Core引入到Windows桌面应用程序框架中，包括WPF和Windows Forms。这意味着您的客户端应用程序将能够利用.NET Core中引入的各种性能改进，并且您将能够将它们部署为自足的可执行文件（.exe），这些可执行文件对任何预装的.NET版本都没有依赖性。
本文提供了对.NET Core使用的新项目格式的快速介绍，以及如何使用命令行接口（CLI）来创建、构建和部署在.NET Core上运行的自包含和框架依赖的桌面应用程序。您已经能够这一段时间使用预发布版本的SDK，但由于上周公布了.NET Core 3和Visual Studio 2019的官方预览版本，现在是时候熟悉WPF和Windows Forms多年来最大的现代化。
.NET Core
你可能已经非常清楚，.NET Core是微软的开源和跨平台版本的.NET，他们最近的大部分开发工作都集中在这里。他们对运行时和核心库都做了一些显著的性能改进，同时还引入了一堆新的类型，使其更容易开发出能在所有主要操作系统上运行的前沿应用程序。最新的稳定版本是2.2，也是上周发布的。
.NET框架
.NET框架是经典的Windows专用版本的.NET，自2002年以来，已经有超过10亿台PC设备安装了它。自4.0版本以来，所有对.NET框架的更新都是就地更新。这意味着，当安装更新时，总是存在着以某种方式破坏现有应用程序的风险。即使针对早期版本的框架的现有应用程序实际上并没有针对新的框架版本进行重新编译，它仍然会受到就地更新修改了作为框架一部分的一些汇编的代码这一事实的影响。这个众所周知的可组合性问题显然是微软选择并继续选择不将他们在.NET Core中引入的大部分功能和改进移植回.NET框架的主要原因之一。
有了.NET Core带来的并列支持，你可以安装一个使用.NET最新特性的新应用程序，而不用承担破坏现有应用程序的风险。关于.NET框架的 "完整 "桌面版本（目前处于4.7.2版本）的可靠性和稳定性问题，实际上意味着它将进入 "仅有热补丁 "的模式。在未来的几年里，它仍然会得到全面的支持，因为它是Windows的重要组成部分，但如果你想在未来利用.NET的最新功能，你迟早要针对.NET Core。
.NET Core 1.0 - 2.2
到目前为止，只有ASP.NET网站、服务和控制台应用程序能够针对.NET Core，但从.NET Core 3.0版本开始，它也适用于WPF、Windows Forms和通用Windows平台（UWP）应用程序。你可能会问自己，这是否意味着你将能够在Linux或Windows以外的任何其他平台上运行WPF应用程序？恐怕这个问题的答案是否定的。虽然.NET核心本身是并将继续是一个开源框架，用于构建可在所有主要平台上运行的高性能应用程序，但桌面框架仍然只针对Windows。它们将作为分层在.NET Core之上的桌面包交付，类似于现有的Windows兼容性包，它是.NET标准2.0的逻辑扩展，并提供对Windows特定API的访问。
命令行界面（CLI）
如果你从微软官网下载并安装了.NET Core 3的预览版，或者从GitHub下载并安装了包含最新位的.NET Core SDK for Windows的预发布版本，那么你今天就可以开始创建针对.NET Core的客户端应用程序了。使用CLI从开发者命令提示符中发出以下命令，可基于默认项目模板创建一个新的WPF项目。
dotnet new wpf --output WpfCoreApp1
Windows Forms项目的相应模板也被添加到模板引擎中。您可以使用 dotnet new -all 命令列出所有可用的模板。
Csproj格式
--output（简称-o）选项指定了生成项目文件的位置。如果你在运行命令后检查这个文件夹中的文件，它们应该看起来很熟悉。App.xaml和MainWindow.xaml看起来很像Visual Studio在创建一个新的以.NET框架为目标的WPF应用程序项目时创建的那些文件。如果你看一下项目文件(.csproj)，你会发现，与.NET框架项目相比，它有一个新的精简和干净的格式。
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>
</Project>
通过.NET Core SDK使用的新的csproj格式，无需使用Visual Studio就能更容易理解和手动修改项目文件。你不再需要在项目中明确引用和包含文件。与.csproj文件本身在同一文件夹中的源文件和资源，只要它们符合特定SDK中定义的模式，即由项目文件中第一行的Project元素中新的强制性Sdk属性所指定的模式，就会被隐含在项目中。
SDK
SDK，或者在官方文档中称为共享SDK组件，是一组知道如何构建.NET Core代码的MSBuild任务和目标。以前版本的.NET Core工具包括用于构建和发布Web应用程序的Microsoft.NET.Sdk.Web，用于构建ASP.NET MVC razor视图和布局的Microsoft.NET.Sdk.Razor，以及用于构建非基于Web的应用程序的Microsoft.NET.Sdk。
Microsoft.NET.Sdk.WindowsDesktop是一个新的SDK，它包含了桌面包，其中包含了GUI框架的特定程序集，例如PresentationCore.dll和System.Windows.Forms.dll。它被安装到C:\Program Files\dotnet\sdk\{version}\Sdks\Microsoft.NET.Sdk.WindowsDesktop中，其中{version}是你的开发机器上当前安装的.NET Core SDK的版本。您可以使用dotnet --version命令显示当前使用的版本。
MSBuild的内部工作原理不在本文讨论范围内，但如果你在文本编辑器中打开Sdk/Sdk.target文件，你会发现Microsoft.NET.Sdk.WindowsDesktop SDK导入Microsoft.NET.Sdk来引入.NET Core的东西，而Windows桌面特定的构建细节是在target文件夹中的文件中定义的。在target/Microsoft.NET.SDk.WindowsDesktop.props中，定义了前面提到的包含项目中所有XAML文件的glob模式。该文件还使用项目文件中元素的值来决定在Visual Studio中构建项目并为其提供工具支持时要引用哪些汇编。Windows Forms项目也有相应的元素，如果你的应用程序同时使用这两个框架，你可以在同一个项目文件中使用这两个元素。
当然，在开发和构建应用程序时，你并不需要真正关心这些细节。如果你在Visual Studio中打开项目，你将能够像你习惯的那样添加断点、构建和调试你的代码，而不需要知道任何关于应用程序如何被构建和由幕后工具为你处理的细节。如果你查看项目引用，并在解决方案资源管理器中展开SDK节点，你会发现它由Microsoft.NETCore.App和Microsoft.WindowsDesktopApp组成。前者的SDK包括所有属于.NET Core的核心程序集，后者包括所有Windows特定的程序集，它包含在桌面包中。顺便说一下，WPF和Windows Forms都使用一个桌面SDK。Visual Studio 2017并没有正式支持.NET Core 3项目，但Visual Studio 2019将支持。第一个预览版可以在这里下载。
包引用
关于新的项目格式，另一个需要提及的是，不再需要单独的package.config文件来跟踪NuGet依赖关系。当你将一个NuGet包添加到传统的.NET框架项目中时，会有一个元素添加到项目文件中，用于安装包的每个依赖关系。例如，如果你安装了一个NuGet包，而这个包又依赖于其他三个包，那么你总共会得到四个元素。此外，包的信息在packages.config文件中是重复的。
在.NET Core项目中，实际安装的NuGet包只有一个转折元素添加到.csproj文件中，例如。
<ItemGroup>
<PackageReference Include="newtonsoft.json" Version="12.0.1" />
</ItemGroup>
任何依赖关系都会在构建时自动包含。您可以在Visual Studio中通过在解决方案资源管理器中展开Dependencies->NuGet树来查看包的依赖关系。
多目标
新的项目系统还允许你使用同一个项目文件来针对多个.NET运行时。这是在开发库时比较常见的事情，但它当然也可以在可执行应用程序中实现。例如，如果您希望您的WPF应用程序同时针对.NET Core和.NET Framework，您可以简单地将项目文件中的<TargetFramework>元素重命名为<TargetFrameworks>（在结尾处增加一个 "s"），并指定一个分号分隔的列表，其中包含所有您希望针对的框架，例如：
<TargetFrameworks>netcoreapp3.0;net452</TargetFrameworks>
net452是.NET框架4.5.2的TFM。所有支持的框架和它们的代号都在MSDN上列出。
如果你使用dotnet build命令，或者使用Visual Studio构建应用程序，你将得到一个为你在项目文件中指定的每个目标框架创建的输出文件夹。在这种情况下，bin/debug/debug/netcoreapp3.0中的编译应用程序将在.NET Core上运行，而bin/debug/net452中的应用程序将在.NET Framework上运行。
部署
当涉及到应用程序部署时，.NET Core支持两种不同的模式：框架依赖型和自包含型。自足方式将您的应用程序特定代码与.NET Core运行时和库捆绑在一起，以创建一个基本不依赖运行时环境的应用程序。当您构建这样一个自包含的应用程序时，您必须指定目标操作系统（OS）。目标操作系统是使用运行时标识符（RID）来指定的，您可以将这个标识符包含在项目文件中的元素内，或者在您使用 CLI 发布应用程序时使用 --runtime (-r) 选项来指定它。
dotnet publish --runtime win-x64 --framework netcoreapp3 --configuration release --output bin/self-contained/
对于WPF和Windows Forms应用程序，您可以使用win-x86或win-x64或任何其他特定版本的Windows RID。请注意，如果您使用<TargetFrameworks>元素在您的项目文件中针对多个框架，您还必须使用--framework (-f)选项指定一个目标框架。
依赖于框架的应用程序是使用相同的发布命令创建的。如果你在项目文件中包含了<RuntimeIdentifier>元素，你可以使用--self-contained选项，其值为false，以只部署你的应用程序和它可能有的任何第三方依赖关系。否则你可以不使用 --runtime (-r) 选项。
版本滚动
当运行依赖框架的应用程序时，它将使用目标机器上存在的.NET Core的最新补丁版本。这意味着，如果应用程序是在开发机或构建代理上针对目标框架netcoreapp3（版本3.0.0）构建的，而目标机上最新安装的.NET运行时是3.0.1版本，则应用程序将使用后一个运行时版本运行。如果没有安装3.0.*版本，将使用最高的3.*版本。
对于独立部署，运行时版本选择发生在您发布应用程序时，而不是在您运行它时。发布过程会默认选择最新的补丁版本并捆绑应用程序。MSDN上详细解释了为.NET Core应用程序选择实际运行时版本的滚转策略。
依赖于框架的部署的主要优势是应用程序的大小将更小，因为它不包括.NET Core本身。如果你比较一下自包含和依赖框架发布的应用程序之间输出文件夹的内容，你会发现前者包含了更多的程序集。
可移植性
除了对项目文件和工具的更改，在决定升级现有的.NET Framework应用程序以瞄准新的运行时之前，您还需要确保您没有使用任何尚未移植到.NET Core的API。有一个可供下载的可移植性分析工具可以帮助你做到这一点。它是一个简单的Windows Forms应用程序，让您选择一个包含一些汇编的文件夹进行分析。它产生一个Excel文件（.xlsx），告诉你这些程序集中使用的哪些类型和成员在.NET Core中不支持。尽管许多最常见的.NET框架API已经被移植过来，但仍有一些缺失。您必须在您的代码中替换这些API，才能升级到.NET Core。
不久之后，.NET Core 3和Visual Studio 2019的最终版本就会发布，引用.NET官方博客的话说，如今成为一名.NET开发人员，确实是一个令人兴奋的时刻。你不同意吗？
通过www.DeepL.com/Translator（免费版）翻译
