64 位世界中的 WinForms – 我们的未来战略

本文主要是介绍64 位世界中的 WinForms – 我们的未来战略，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：Klaus Loeffelmann
排版：Alan Wang

作为一个依靠创新和发展而蓬勃发展的社区的一部分，WinForms 开发人员经常突破界限来创造新的可能性。我们的开发人员还负责维护业务软件的关键任务线，这通常需要十年以上的时间。我们重视您的信任和您对使用我们的工具创建出色的软件解决方案的热情。如您所知，Visual Studio 2022 从 32 位到 64 位的过渡引发了一些复杂问题。我们了解到这些变化在你们的开发过程中造成了一些麻烦，因此我们希望通过指出现有的解决方法以及我们针对这些问题的准备计划来澄清这些问题。

拥抱 64 位：更好的改变

转向64 位平台不仅仅是简单的升级。这是一项重大改进，可以在多个方面帮助 Visual Studio 更好地工作。最大的好处之一是能够使用更多内存。在 32 位版本中，Visual Studio 可以使用的内存量受到限制，通常这会导致性能下降，甚至在处理大型项目时出现错误。 64 位版本消除了这些限制，使 Visual Studio 能够以更高的效率处理更大的项目。
在这里插入图片描述
但这不仅仅是获得更多内存的问题。切换到 64 位还使 Visual Studio 能够更好地利用计算机的处理器，尤其是它的多核。由于 64 位应用程序可以一次处理更多数据，因此它可以同时有效地使用更多内核，从而实现更快的操作。这在构建项目时尤其明显。如果您的项目很大，包含许多文件和代码，则 64 位上的构建操作会快得多。这意味着减少等待构建完成的时间，从而帮助您更快地完成工作。但这些并不是唯一的优势。其他还有：

与 64 位库的兼容性：有许多 64 位库和组件根本无法在 32 位版本的 Visual Studio 中有效使用。64位版本可以更好地利用和整合这些资源。
增强的安全性：与 32 位系统相比，64 位系统具有一些内置的安全优势，包括称为地址空间布局随机化（ASLR）的功能，该功能使恶意代码更难以利用系统。
面向未来：随着技术的不断发展，越来越多的应用程序和操作系统正在向 64 位架构过渡。通过迁移到 64 位，Visual Studio 正紧随潮流，确保与未来技术进步的兼容性。
更大的数据集：使用64位计算，您可以处理更大的数据集，这些数据集以前可能由于内存限制而无法处理。这在数据密集型领域（如机器学习、大数据分析）的设计阶段尤其有利，但也适用于涉及处理大型复杂数据库模式的任务（例如代码生成）。

WinForms 适用于哪里？

这些优点也适用于 WinForms Designer。对于 WinForms 应用程序来说，反映复杂的业务案例是很常见的。因此，这些应用程序通常包含数百个表单和用户控件，它们本身可能会变得非常庞大和复杂。所有这些都会导致在编辑表单时需要立即生成大量代码。因此，WinForms Designer 无疑是64位过渡的最大受益者之一。Designer 利用了在64位架构中访问更多内存的能力，大大提高了处理复杂设计任务的性能和能力。

32 位遗留组件的挑战

综上所述，我们充分意识到，这一进步给绑定到 32 位体系结构并在 Windows Forms 设计器上下文中使用以定位 .NET Framework 版本（最高版本 4.8.1）的某些组件带来了挑战。

从 32 位系统到 64 位系统的转变不仅仅是为了提高性能，还涉及基本的架构变化。这些变化直接影响我们管理 .NET Framework 版本和 .NET Core 应用程序的方式。例如，无法在 64 位进程中托管 32 位独占组件，也无法在 .NET Framework 进程中托管 .NET Core 类型。然而，这不应该被视为一种可以避免的方法。相反，它是技术自然进步和进化的必要组成部分。

我有什么选择？

您可以考虑多种途径，每种途径都有其自身的优点：

迁移到 .NET 8+：最具前瞻性的选择是升级到 .NET 8 或更高版本。.NET 8+ 环境是（不仅仅是）WinForms 应用程序开发的未来，且提供了最强大的支持，特别是在涉及第三方控件供应商时。借助 .NET 8+，您不仅能跟上时代的步伐，还能保持领先地位，确保您的应用程序为未来的任何情况做好准备。
使用 AnyCPU：首先，在设计时，将所有内容切换为使用“AnyCPU”进行构建。 Visual Studio 中的“AnyCPU”编译选项为 WinForms 项目中的 32 位组件问题提供了通用的解决方案。当你的项目设置为“AnyCPU”时，Visual Studio 将编译你的应用程序，使其可以在32位和64位平台上运行。在设计时，这种灵活性意味着您的进程可以在 64 位系统上以 64 位方式运行，从而使您能够充分利用 64 位 Visual Studio 的优势，例如改进的内存利用率和更快的操作。在许多情况下，这对于需要 32 位运行时组件的项目来说非常有效。当涉及到设计会话完成后的运行时，“Prefer 32-bit”项目设置就成为了与旧的 32 位组件或库兼容的关键。通过启用此设置，您可以指示公共语言运行时（CLR）在 32 位进程中运行“AnyCPU”编译的应用程序，甚至在 64 位系统上也是如此。这为您的 32 位组件提供了一个按预期运行的环境，使您的应用程序保持平稳运行。虽然这种方法确实施加了一些 32 位限制，例如较小的内存空间，但它提供了一种有效的解决方案，可以平衡 64 位设计时功能的需求和运行时 32 位组件的需求。
现代化 32 位组件：如果第一个选项由于 32 位组件的架构而不可行，您可能会考虑迁移出 32 位组件。虽然这可能需要投入时间和资源，但从长远来看，您将获得的好处是巨大的。过渡到 64 位环境不仅可以提供更好的性能，还可以增强安全性。此外，它还会为您的应用程序做好未来更新和改进的准备，确保其使用寿命。

如果所有这些选项都不适合您的特殊情况，那么最后一个选项就是进程外 WinForms Designer：

适应新格局：进程外设计器

为了支持 .NET Core 3.1 及更高版本，我们创建了 WinForms Designer 的进程外版本；一个单独的进程，可以处理 Visual Studio 无法作为 .NET Framework 进程执行的任务。这本质上要求我们创建一个全新的架构和可扩展性模型来同时处理两种类型的流程。升级到 .NET 确实面临着运行时和新的进程外设计器中的变化带来的挑战。虽然我们确实在最重要的设计时功能方面保持一致，但在某些情况下，传统方法在新技术领域中不再有意义。

进程外设计器允许我们规避进程内设计的限制，即托管组件与托管设计器的目标框架（例如 Visual Studio）不兼容的问题。这是通过启动一个新的设计器进程来完成的，然后该进程在与 WinForms 项目设置的目标框架版本中运行，从而允许更灵活地管理不同架构的组件。

此外，进程外设计器允许我们为更高版本的 .NET 提供支持，例如 .NET 8、9 及更高版本。它通过允许组件利用这些较新版本的 .NET 中可能与 .NET Framework 不兼容的功能来实现此目的。

然而，这也意味着必须调整所有单独的组件及其控制设计器以跨不同的流程边界工作。当您使用自己的 WinForms 控件库时，通过专用的控件设计器（提供自定义 CodeDOM 序列化、专用类型编辑器、自定义装饰器渲染或个性化 Designer 操作项）提供高度自定义设计时支持，您需要迁移 Designer 代码以使用 WinForms 设计器 SDK。通过 .NET（Core、5+）中的库存控制，我们在这一领域取得了长足的进步。同样重要的是：我们大多数较大的第三方控制库合作伙伴也提供用于 .NET 版本 5、6 和 7 的产品 - .NET 8 的现代化版本正在制作中。

值得注意的是，当我们解决这些问题时，我们会根据使用情况对组件进行优先级排序。.NET Core 中一些不太常用的组件的设计器支持已被弃用，取而代之的是更常用的组件。

具有 32 位组件的 .NET Framework 应用程序的进程外设计器

我们发现更多的人需要支持为 32 位 .NET Framework 设计 WinForms 应用程序，因为这些应用程序使用只能在 32 位进程中运行的组件。因此，我们采用了 .NET 的 WinForms 进程外设计器的方法，并在此基础上引入了 32 位进程外 .NET Framework 设计器。

进程外设计器旨在生成一个单独的 32 位进程，该进程可以托管此类应用程序所需的组件。通过这样做，它避免了 Visual Studio 的 64 位环境与 32 位组件之间的不兼容性。尽管系统架构存在差异，但这种设计可以实现更平滑的集成和兼容性。

如果您尝试打开一个引用 32 位组件的 WinForms .NET Framework 项目，Visual Studio 将自动弹出一个对话框并询问您是否要使用 32 位 .NET Framework 流程外设计器打开项目。
在这里插入图片描述
就像 .NET 的对应工具一样，32 位 .NET Framework WinForms 应用程序的进程外设计器旨在提供相同的设计时体验，保留使用现有（甚至是遗留）32 位组件的能力。尽管弥合架构差距的任务艰巨，但我们致力于确保平稳过渡并维护您所依赖的功能，同时还提供未来升级和增强的途径。

我们知道重要的旧项目可能依赖于 32 位 ActiveX 控件和其他当前与 Visual Studio 2022 不兼容的旧组件，特别是那些不面向 .NET（Core、5+）但面向 .NET Framework（最高版本 4.8.1）的项目. 在这些情况下，流程外设计器可以成为许多用例的解决方案。但请注意，.NET（6+）WinForms 进程外设计器也应被视为首选和最佳实践方式 - 您将获得两全其美的好处：设计时和运行时的 32 位兼容性以及最新、最现代、性能最强的 .NET 版本。

值得注意的是，更新的进程外 32 位 .NET Framework 设计器将无法实现与旧的进程内 .NET Framework Designer的完全同等，因为 .NET Core 的进程外设计器提到的相同架构差异。这也意味着高度自定义的控件设计器与开箱即用的 .NET Framework 进程内设计器不兼容。如果您使用来自第三方的自定义控件库，您需要检查他们是否提供支持进程外 .NET Framework Designer 的版本。

支持遗留组件：我们的承诺和计划

进程外设计器是我们未来投入大部分精力的地方。这是我们今年的路线图规划：

改进 32 位框架进程外设计器：此设计器将是维护项目的选择，这些项目无法迁移到 .NET（Core、5+），但依赖于旧版 32 位组件。该设计器不会与进程内设计器具有相同的功能，但我们将根据客户需求添加更多功能。请注意，32 位框架设计器已处于预览状态，可以通过“工具/选项”页面激活。

对于 Visual Studio 2022 版本 17.9，我们发布了一项功能，它可以帮助您轻松选择是否应该为经典 Visual Studio 进程内设计器或进程外设计器打开 .NET Framework 项目。与经典 WinForms 进程内设计器相比，差异如下：

您将能够打开和设计面向 .NET Framework（最高版本 4.8.1）并依赖于基于 32 位的 ActiveX 组件或大多数其他原因的表单和用户控件，这将强制生成的程序集在设计器中为 32位。
如果您的项目依赖于特殊的第三方控制库，而这些控制库依赖于遗留的32位组件，那么您不能使用第三方供应商为经典的进程内设计器提供的相同版本的控制库。请咨询您的控件库供应商，看看他们是否为 .NET Framework 进程外设计器提供了更新版本。
在设计数据集上下文中，类型化数据集设计器和 SQL Server 查询编辑器仅适用于经典的进程内设计器。但是，我们将在今年晚些时候推出新功能，以便继续支持维护基于现有数据源数据绑定场景，这使得使用基于现有类型化数据集的数据源变得更加容易和可能。不过，目前我们还没有计划在 .NET Framework 进程外设计器中支持经典数据源工具窗口。
.NET 或 .NET Framework 应用程序的进程外设计器将不支持基于经典 SOAP Web 服务的数据源。
为根设计器提供基础设施：第三方供应商和控件库作者依赖根设计器 - 例如，当他们想要将报表设计器从 .NET Framework 迁移到 .NET Core 时。通过向进程外设计器添加根设计器支持，我们将使控件作者能够对其强大的报告设计器和其他文档设计器类型进行现代化改造，并将它们引入 .NET 6、7 和 8+。但是，我们目前没有计划支持 .NET Framework 进程外设计器的自定义根设计器。

向前迈进：共同努力

向 64 位系统的过渡是一个重要的里程碑，需要采用新的方法、创新的解决方案和耐心。如前所述，这不是一个快速的问题修复；相反，它是我们需要作为一个社区去共同管理的过渡。

我们致力于让您的旅程尽可能顺利。您的反馈非常宝贵，它可以帮助我们确定需要重点努力的领域。我们已经制定了路线图，并且正在取得进展，但完成的时间取决于您向我们提出的独特挑战。

总之，我们了解您所面临的复杂性，并且我们想向您保证在应对这些挑战方面正在取得进展。请记住，改变通常会带来一些不适，但它为成长和更好的结果铺平了道路。我们想强调您在这一持续过渡中积极参与的重要性。随着我们不断努力改进和微调 64 位设计器以及我们的进程外设计器支持，您的反馈和错误报告非常宝贵。如果您在使用 WinForms 时遇到任何特定问题，我们强烈建议您直接在 GitHub 上的 WinForms 存储库中或通过 Visual Studio 的反馈功能报告这些问题。详细、具体的问题报告，尤其是那些包含环境信息、重现步骤和具体错误消息的报告，可以极大地帮助我们更有效、更快速地识别和解决问题。您在此过程中的参与对于成功开发更强大、更高效的 Visual Studio 至关重要，因为许多技术和遗留的32位组件已经有20年甚至更长的历史。