简介
Windows App SDK提供了一组广泛的 Windows API，其中包含从 OS 分离的实现，并通过 NuGet 包发布到开发人员。 作为具有Universal Windows Platform（UWP）应用程序的开发人员，可以通过将应用移动到Windows App SDK，充分利用现有技能集和源代码。
借助Windows App SDK，可以将最新的运行时、语言和平台功能合并到应用中。 由于每个应用程序都不同，要求和偏好也不同，因此有许多不同的方法来迁移应用的源代码。 但是，高级方法以及各种功能区域所需的代码更改是类似的。 因此，在本主题中，我们将回顾迁移应用的策略，以及有关某些功能区域的详细信息（及限制）。 因此，另请参阅从 UWP 移植到 WinUI 3 时支持的功能。
Windows App SDK应用可以使用大多数 Windows Runtime （WinRT） API。 但有一些在桌面应用中不受支持或存在限制。
- 依赖于 UI 功能的 API，这些功能仅在 UWP 应用中可用。
- 需要包标识的 API。 这些 API 仅在使用 MSIX 打包的桌面应用中受支持。
对于这些 API，我们将展示要使用的替代方法。 大多数替代项在 WinUI 中或通过 Windows App SDK 中提供的 WinRT COM 接口提供。
例如，我们会遇到某些用户界面场景，在这些场景中，您需要跟踪主窗口对象，并使用各种基于HWND的API和互操作模式，例如IInitializeWithWindow::Initialize。
注意
另请参阅桌面应用中不支持的 Windows Runtime API。 Windows App SDK应用是一种桌面应用。 其他类型的桌面应用包括.NET桌面应用和 C/C++ Win32 桌面应用。 该主题的受众是希望迁移到包括但不限于 Windows App SDK 应用在内的不同类型桌面应用联合中的任何项目的开发人员。
我们很想了解你对本迁移指南的反馈，以及你自己的迁移体验。 使用本页底部的“反馈”部分，如下所示：
- 有关Windows App SDK的问题和反馈，或只是为了开始讨论，请使用 This product 按钮。 还可以开始讨论 Discussions 选项卡WindowsAppSDK GitHub 存储库。 使用这些渠道，还可以告诉我们要尝试解决什么问题、到目前为止如何尝试解决该问题，以及什么是应用的理想解决方案。
- 有关此迁移指南中缺失或不正确的信息的反馈，请使用“此页面”按钮。
为什么迁移到Windows App SDK？
Windows App SDK提供了使用新平台功能增强应用的机会，以及新式 Windows UI 3 库（WinUI），这是开发和设计为令用户高兴的。
此外，Windows App SDK 后向兼容；它支持最低到 Windows 10 版本 1809（10.0；内部版本 17763），即通常所称的 Windows 10 2018年10月更新。
移动Windows App SDK的价值主张是多管齐下。 下面是一些注意事项：
- 最新的用户界面（UI）平台和控件，如 WinUI 3 和 WebView2。
- 跨桌面应用平台的单一 API 接口层。
- 更频繁的发布节奏，与 Windows 分开发布。
- 在多个 Windows 版本中实现一致体验。
- .NET兼容性。
- 向后兼容到 Windows 10 版本 1809。
- 改进运行时环境。 请参阅 MSIX 容器。
有关详细信息，请参阅 Windows App SDK。
迁移过程概述
注意
可以将要迁移的应用的 UWP 版本视为 源 解决方案/项目（它是迁移过程的 源）。 Windows App SDK版本是目标解决方案（它是迁移过程的目标）。
安装Windows App SDK VSIX
从 Windows App SDK 下载最新的Windows App SDK版本并运行以安装它。
创建新项目
在 Visual Studio 中，创建第一个 WinUI project。 例如，使用 Blank App， Packaged （Desktop 中的 WinUI） project 模板。 可以在“创建新项目”对话框中找到该项目模板，通过选择语言：C#或C++；平台：Windows App SDK；项目类型：WinUI或Desktop。
你将在 Solution Explorer 中看到两个项目—一个项目被限定为 （Desktop），另一个项目称为 （Package）。
首先迁移依赖项最少的代码
为了说明此建议，让我们以 PhotoLab 案例研究为例。 对于 PhotoLab 示例应用，一种显而易见的方法是先迁移“MainPage”，因为这是应用重要且突出的一部分。 但是，如果我们那样做，那么我们很快就会意识到MainPage依赖于DetailPage视图，接着DetailPage依赖于Photo模型。 如果我们沿着这条路走，那我们可能会不断打断自己的工作（切换去处理每一个新发现的依赖项）。 当然，我们不期望得到一个干净的构建，直到我们解决每个依赖项，并在一次重大的迁移中基本上移植整个项目。
另一方面，如果我们从不依赖于其他东西的项目开始，并从那里逐步扩展（从最不依赖的部分到最依赖的部分），那么我们就能一次专注于每一个部分。 我们还能够在迁移每个部分后实现无错误构建，并以这种方式确认迁移过程是否保持在正轨。
因此，在迁移自己的应用时，建议首先迁移依赖项最少的代码。
复制文件，还是复制文件内容？
迁移时，当然会复制资产文件（而不是资产文件内容）。 但是，源代码文件呢？ 例如，让我们再次从 PhotoLab 案例研究和照片编辑器案例研究中获取 MainPage 类。
C#. 在 C# 版本 (PhotoLab) 中，“MainPage”由源代码文件 MainPage.xaml 和 MainPage.xaml.cs 组成。
C++/WinRT。 在 C++/WinRT 版本（照片编辑器）中，“MainPage”由源代码文件 MainPage.xaml、MainPage.idl、MainPage.h 和 MainPage.cpp 组成。
因此，可以选择以下两个选项：
- （建议）您可以复制文件本身（使用文件资源管理器），然后将副本添加到目标项目中。 此建议的例外情况是文件（如
App.xaml和App.xaml.cs），因为这些文件已存在于目标project中，并且它们包含特定于Windows App SDK的源代码。 对于这些，你需要将已有的源代码与源项目中的源代码进行合并。 - 也可以使用Visual Studio在目标project中创建新的 Page 文件（如
MainPage.xaml和MainPage.xaml.cs）， 然后将这些源代码文件的 contents从源project复制到目标project。 对于 C++/WinRT project，此选项涉及更多步骤。
另请参阅MainPage 和 MainWindow部分。
文件夹和文件名差异 (C++/WinRT)
在 C++/WinRT 的 UWP 项目中，XAML 视图的代码隐藏文件命名格式为 MainPage.h 和 MainPage.cpp。 但在 C++/WinRT Windows App SDK中，需要将这些项重命名为 MainPage.xaml.h 和 MainPage.xaml.cpp。
在 C++/WinRT UWP 项目中，迁移名为 MyPage 的假设 XAML 视图（从模型、视图和视图模型的意义上而言）时，需要在 #include "DetailPage.xaml.h" 后立即添加 #include "MyPage.g.cpp"。 对于名为“MyModel”的假设模型，在 MyModel.cpp 中 #include "MyModel.h" 之后立即添加 #include "MyModel.g.cpp"。 有关示例，请参阅迁移 DetailPage 源代码。
如果更改迁移的项目名称
在迁移过程中，您可能会选择为目标项目赋予一个不同于源项目的名称。 如果这样做，这将影响源project中的默认命名空间。 将源代码从源project复制到目标project时，可能需要更改源代码中提到的命名空间名称。
在我们研究的实例中，例如 Windows 应用程序 SDK 迁移 UWP PhotoLab 示例应用程序（C#），我们会更改项目名称（因此默认命名空间名称）。 在该案例研究中，我们使用文件资源管理器复制整个文件，而不是从源项目复制文件内容到目标项目。 源project/命名空间名称为 PhotoLab，目标project/命名空间名称为 PhotoLabWinUI3。 因此，我们需要在复制的任何源代码文件的内容中搜索 PhotoLab，并将其更改为 PhotoLabWinUI3
在这一特定案例研究中，我们在App.xaml、App.xaml.cs、MainPage.xaml、MainPage.xaml.cs、DetailPage.xaml、DetailPage.xaml.cs、ImageFileInfo.cs和LoadedImageBrush.cs中进行了以下更改。
安装相同的 NuGet 包，这些包是此前在源项目中安装的。
迁移过程中的一项任务是标识源project依赖的任何 NuGet 包。 然后在目标project中安装这些相同的 NuGet 包。
例如，在案例分析 A Windows App SDK UWP PhotoLab 示例应用（C#）中，源项目包含对 Microsoft.Graphics.Win2D NuGet 包的引用。 因此，在该案例研究中，我们在目标项目中添加对同一 NuGet 包的引用。
