32位WinForms设计器选择。NET框架项目

Visual Studio 2022向64位体系结构的过渡，是在所有Visual Studio开发人员的客户反馈的推动下，朝着增强开发体验迈出的关键一步。正如克劳斯·洛夫曼在他的博客文章这种转换提高了总体性能和响应能力，尤其是在处理资源密集型任务和大型代码库时。然而，这种演变给一些人带来了显著的挑战。NET Framework项目使用Visual Studio 2022中的Windows窗体设计器。挑战在于无法在中设计表单。NET Framework项目依赖于32位引用，这是由于64位devenv.exe Visual Studio进程无法加载32位编译的引用的固有技术限制。对于使用Windows窗体的用户来说，这个特定的障碍已经成为一个重要的采用障碍。NET Framework项目广泛利用ActiveX/COM控件或嵌入32位程序集中的其他自定义控件。到目前为止，此类场景的解决方案是使用Visual Studio 2019，其中Windows窗体设计器作为32位进程运行，以满足这些项目的特定需求。

认识到这种转变带来的局限性及其对开发人员的影响，我们一直在努力开发各种功能，为设计传统的32位WinForms铺平道路。最新Visual Studio环境中的NET Framework应用程序。虽然这些最初的努力并不能全面解决整个问题空间，但我们的目标是疏通客户，使向64位Visual Studio 2022的过渡更加顺利。

在最新的Visual Studio 2022版本v17.9中，WinForms团队引入了一个预览功能——进程外设计器支持。NET Framework项目。能够使用我们的进程外设计器。NET框架目前处于早期预览状态，我们急切地寻求开发人员的反馈，以完善和改进其功能。值得注意的是，Visual Studio 17.9版本带来了关键的增强功能，包括：

• 改进了的类型分辨率。NET Framework项目
• ActiveX/COM支持两者。NET框架和。NET项目
• 用于监视中32位程序集加载失败的新设计器选择功能。NET Framework项目

这些添加意味着我们致力于积极参与社区活动，了解他们项目的复杂性，并稳步构建为最佳Visual Studio体验铺平道路的功能。我们希望这种方法将使开发人员最终更容易迁移到。NET来获得更现代平台的所有好处，而无需完全重写用户界面。

什么是设计师选择功能？

当WinForms设计器检测到32位程序集加载失败时，它会显示以下对话框，该对话框提供了为开发人员项目选择适当设计器的选项：

通过选择“是”，项目将被重新加载，Windows窗体进程外设计器开始发挥作用。如果项目以x86为目标，则设计器将启动32位进程以在设计器中呈现窗体。该进程被标识为“FxDesignToolsServer.exe”在此过程中，将加载控件程序集，并执行与指定框架对齐的“InitializeComponent”方法中的代码。

选择“否”后，项目将继续使用进程内设计器，尽管您仍然无法设计引用32位组件的表单，因为32位二进制文件无法在64位进程中加载。

使用“是/否”按钮，设计器选择将只记住当前Visual Studio实例的此设置。要将设计器选择自动添加为项目配置属性，请启用选项“记住当前项目”它会将“UseWinFormsOutOfProcDesigner”属性添加到每个项目配置中。下次在Visual Studio中打开项目时，WinForms Designer将读取此属性值以自动选择所需的Designer版本（In-Process或Out-Of-Process）。以下是添加此属性后的项目配置示例：

<PropertyGroup Condition=“'$（配置）|$（平台）'=='调试|AnyCPU'”><PlatformTarget>x86</PlatformTarget><OutputPath>bin\Debug\<UseWinFormsOutOfProcDesigner>True</PropertyGroup（属性组）>

请注意，设计器选择功能当前处于以下预览功能标志下，该标志在Visual Studio 2022 17.9中默认启用：

您可以在下的Visual Studio中启用或禁用该功能工具->选项->预览功能.

使用的进程外设计器时，将显示以下信息栏。NET Framework项目：

 

此功能做什么和不做什么。

与将所有与第三方控件相关的程序集加载到Visual Studio进程中的进程内设计器相比，进程外设计器需要更挑剔；它将设计时程序集加载到专用服务器进程或客户端Visual Studio进程中。由于进程外设计器的客户端-服务器体系结构，程序集加载中的这种区别是必要的，因此，第三方控件供应商需要使用新的设计器SDK为进程外设计器提供控件。请注意，为客户端和服务器进程创建不同的设计时程序集对于支持简单场景来说不是必需的，但对于更高级的场景来说却是必需的。了解更多信息在这里。因此，的进程外设计器。NET Framework项目将无法处理为进程内设计环境设计的所有第三方控件。如果遇到这样的控件，可能只会忽略与设计器无法呈现的控件相关的代码。因此，我们建议您事先创建项目的备份。

• 项目中引用的控件将不会出现在工具箱中，以便在解决方案中的其他表单中使用。我们的目标是在即将发布的版本中添加此功能。
• 在进程外设计器中加载具有自定义CodeDOM序列化程序的控件时，设计器当前将忽略InitializeComponent中生成的代码（因为它无法像以前那样运行CodeDOM序列化程序）。我们希望在未来的版本中添加警告，让您提前知道项目将无法加载特定组件。

旁注：您可能会发现在中的“InitializeComponent”方法中生成的代码存在显著差异。与旧的旧csproj文件相比，使用新的SDK样式项目文件的NET Framework项目。这是因为进程外设计器在遇到SDK风格的项目时，会在后台使用Roslyn来生成代码，而不是使用旧的CodeModel技术。了解有关此功能的更多信息在这里。从长远来看，这对您的代码来说是一个巨大的胜利，并支持未来的多目标和迁移路径。为那些遗留的csproj风格项目生成的代码中可能会有一些小的改动，但这些改动意义不大，如果在VS2019中打开同一个项目，效果会很好。

的路线图。Out-of-Process Designer中的NET Framework项目支持

如本博客前面所述，我们计划在即将发布的Visual Studio版本中，在进程外设计器中添加对以下功能的支持：

• 增强对解决方案中引用的控件的工具箱支持。
• 当设计器无法使用自定义CodeDOM序列化程序加载控件时，会出现更详细的警告。

你能做些什么来为一个64位数的世界做准备？

此功能并不是为了让WinForms的开发人员无操作地过渡到Visual Studio 2022。NET Framework应用程序，在其代码中使用旧的32位组件。自从创建了许多这些遗留组件以来，开发环境发生了巨大变化。例如，其中许多不符合当今的代码安全标准。设计器选择功能以及的相关支持。进程外设计器中的NET Framework WinForms应用程序旨在成为应用程序最终解决方案的短期桥梁。从长远来看，当前使用32位组件的应用程序有两个潜在选项：要么将组件升级到AnyCPU或64位，要么最好将应用程序升级到。NET 8及更高版本。。NET 8平台完全支持WinForms应用程序中的32位COM和ActiveX控件。还有一个稳健的3^第个每天都在增长的政党控制供应商生态系统。

要了解有关WinForms使用32位组件的策略的更多信息，请参阅Klaus Loffelmann和Merrie McGaw最近的博客：64位世界中的WinForms–我们的未来战略.

交割

我们感谢您花时间报告问题/建议，并希望您在使用Visual Studio时继续向我们提供反馈，说明您喜欢什么以及我们可以改进什么。您的反馈对于帮助我们使Visual Studio成为最佳工具至关重要！您可以通过与我们分享反馈开发人员社区：通过报告任何错误或问题报告问题 以及分享你的建议 新功能或现有功能的改进。

关注我们，与Visual Studio团队保持联系YouTube网站，推特，LinkedIn链接，Twitch公司和上的Microsoft学习.