在客户反馈的推动下，Visual Studio 2022 向64位架构过渡，标志着增强开发体验的关键一步。正如 Klaus Loffelmann 在他的博客文章中所描述的那样，这种转换增强了整体性能和响应性，特别是在处理资源密集型任务和大型代码库时。然而，这种演变给一些在 Visual Studio 2022 中使用 Windows 窗体设计器的 .NET Framework 项目带来了显著的挑战。挑战在于无法在 .NET Framework 项目中设计依赖32位引用的 Form，这是固有技术限制的结果，64位的 devvenv .exe Visual Studio 进程无法加载32位编译的引用。对于使用 Windows Forms .NET Framework 项目的用户来说，这个特定的障碍已经成为一个显著的的采用性障碍，这些项目广泛地利用了 ActiveX/COM 控件或嵌入在32位程序集中的其他自定义控件。到目前为止，这种情况的解决方案是使用 Visual Stu服务器托管网dio 2019，其中 Windows 窗体设计器作为32位进程运行，以适应这些项目的特定需求。
认识到这种转变带来的限制，以及它对开发人员的影响，我们一直在努力开发功能，为在最新的 Visual Studio 环境中设计传统的 WinForms 32位 .NET Framework 应用程序铺平道路。虽然这些最初的努力不会全面解决整个问题，但我们的目标是为用服务器托管网户扫清障碍，并让过渡到64位的 Visual Studio 2022 更顺利。
在最新的 Visual Studio 2022 版本 v17.9 中，WinForms 团队引入了一个预览特性——对 .NET Framework 项目的进程外设计器支持。使用 .NET Framework 的进程外设计器的能力目前处于早期预览状态，我们急切地寻求开发人员的反馈，以完善和改进其功能。值得注意的是，Visual Studio 17.9 版本带来了重要的增强，包括:
- 改进了 .NET Framework 项目的类型解析
- ActiveX/COM 支持 .NET Framework 和 .NET 项目
- 一个新的设计器选择功能，用于监视 .NET Framework 项目中的32位程序集加载失败
这些新增功能表明我们致力于积极参与社区，了解他们项目的复杂性，并稳步构建功能，为最佳的 Visual Studio 体验铺平道路。我们希望这种方法能够使开发人员更容易地最终迁移到 .NET ，以获得更现代平台的所有好处，而无需完全重写用户界面。
什么是设计器选择功能?
当 WinForms 设计器检测到32位程序集加载失败时，它会显示以下对话框，其中提供了为开发人员的项目选择适当的设计器的选项：
选择“Yes”，项目将被重新加载，Windows 窗体进程外设计器将开始发挥作用。如果项目的目标是x86，设计器将启动一个32位进程来在设计器中呈现 Form。该进程标识为“FxDesignToolsServer.exe”。在这个进程中，控件程序集被加载，并执行 InitializeComponent 方法中与指定框架对齐的代码。
如果选择“No”，项目将继续使用进程内设计器，尽管您仍然无法设计引用32位组件的Form，因为32位二进制文件无法在64位进程中加载。
使用“Yes/No”按钮，设计器选择将仅为当前 Visual Studio 实例记住此设置。若要自动将设计器选择添加为项目配置属性，请启用“Remember for current project”选项。它将添加“UseWinFormsOutOfProcDesigner”属性到每个项目配置。WinForms 设计器将读取此属性值，以便在下次在 Visual Studio 中打开项目时自动选择所需的设计器版本(进程内或进程外)。下面是添加此属性后的示例项目配置：
" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> x86 binDebug True
请注意，设计器选择功能目前处于以下预览功能标志下，在 Visual Studio 2022 17.9中默认启用:
您可以在 Visual Studio的Tools -> Options -> Preview Features 下启用或禁用该特性。
当您在 .NET Framework 项目中使用进程外设计器时，会显示下面的信息栏:
这个特性能做什么，不能做什么
与将所有与第三方控件相关的程序集加载到 Visual Studio 进程中的进程内设计器相比，进程外设计器要更加挑剔；它将设计时程序集加载到专用服务器进程或客户端 Visual Studio 进程中。由于进程外设计器的客户机-服务器架构，程序集加载中的这种区别是必要的，因此，第三方控件供应商需要使用新的设计器 SDK 来为进程外设计器提供控件。请注意，为客户端和服务器进程创建不同的设计时程序集对于支持简单的场景来说并不是必需的，但是对于更高级的场景来说却是必需的。因此， .NET Framework 项目的进程外设计器将无法处理为进程内设计环境设计的所有第三方控件。如果遇到这样的控件，则可能会忽略与设计器无法呈现的控件相关的代码。因此，我们建议您事先创建项目的备份。
- 项目中引用的控件将不会出现在工具箱中，在解决方案中的其他形式中使用。我们的目标是在即将发布的版本中添加此功能。
- 当在进程外设计器中加载具有自定义 CodeDOM 序列化器的控件时，设计器目前将忽略 InitializeComponent 中生成的代码(因为它不能像以前那样运行 CodeDOM 序列化器)。我们希望在未来的版本中添加警告，让您提前知道项目将无法加载特定的组件。
旁注：您可能会发现，在使用新的 SDK 风格项目文件的 .NET Framework 项目中，与旧的传统 csproj 文件相比， InitializeComponent 方法生成的代码有很大的不同。这是因为进程外设计器在遇到 SDK 风格的项目时，会在后台利用 Roslyn 进行代码生成，而不是使用较旧的 CodeModel 技术。从长远来看，这对您的代码来说是一个巨大的胜利，并且支持未来的多目标和迁移路径。对于那些遗留的 csproj 风格项目生成的代码可能会有一些小的调整，但这些将不那么重要，如果在 VS 2019 中打开相同的项目，将会工作得很好。
进程外设计器支持 .NET Framework 项目的路线图
正如之前提到的，我们计划在即将发布的 Visual Studio 版本中增加对进程外设计器的以下特性的支持:
- 增强工具箱对解决方案中引用的控件的支持。
- 当设计器无法使用自定义 CodeDOM 序列化器加载控件时，会发出更详细的警告。
如何为64位世界做准备?
对于在代码中使用传统32位组件的 WinForms .NET Framework 应用程序的开发人员来说，这个特性并不是为了使过渡到 Visual Studio 2022 没有任何动作。自从创建了许多遗留组件以来，开发环境发生了巨大的变化。例如，它们中的许多不符合今天的代码安全标准。设计器选择功能，以及在进程外设计器中对 .NET Framework WinForms 应用程序的相关支持，旨在为您的应用程序提供最终解决方案的短期桥梁。从长远来看，目前使用32位组件的应用程序有两个潜在的选择：要么将组件升级到 AnyCPU 或64位，要么最好将应用程序升级到 .NET 8 或更高版本。.NET 8 平台在 WinForms 应用程序中完全支持32位 COM 和 ActiveX 控件。还有一个强大的第三方控制供应商生态系统，每天都在增长。
要了解更多关于 WinForms 采用32位组件的策略，请参阅 Klaus Loffelmann 和 Merrie McGaw 最近的博客:《WinForms in a 64-Bit world – our strategy going forward》。
结语
我们感谢您花时间报告问题/建议，并希望您在使用 Visual Studio 时继续给我们反馈，告诉我们您喜欢什么以及我们可以改进什么。您的反馈对于帮助我们使 Visual Studio 成为最好的工具至关重要！您可以通过开发者社区与我们分享反馈，通过发送反馈来报告问题或分享您的建议，推动对新功能或现有功能的改进。
通过在 YouTube, Twitter, LinkedIn, Twitch 和 Microsoft Learn 上关注我们与 Visual Studio 团队保持联系。
原文链接：https://devblogs.microsoft.com/visualstudio/winforms-designer-selection-for-32-bit-net-framework-projects/
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
相关推荐: 云知声持续释放山海大模型商业价值，企业上市备受期待
在中国AI大模型历经日夜星驰的一年里，云知声凭借其深厚的技术积累和对行业趋势的敏锐洞察，站在了大规模行业应用的拐点。近日，在一场关于“国产大模型的365天”的圆桌对话中，云知声创始人兼CEO李霄寒与各行业领袖共同探讨了大模型的发展与应用，揭示了云知声在这一…
