Visual C++ .NET 产品经理为您解答 MFC/ATL 问题。

引言

Nick Hodapp 是 Visual C++ 的产品经理。他也是一位非常友善的人，我经常不公平地给他制造麻烦。我在 2002 年的 VSLive! 旧金山会议上抓住了 Nick，并将我看到 MFC 和 ATL 开发者们不断提出的许多问题转达给他，以便我们能得到一套关于“MFC 是怎么回事”的权威解答。

1. MFC 和 ATL 在 .NET 世界的未来规划是什么？MFC 和 ATL 的生命是否已进入倒计时？

这是一个非常普遍的问题。我确定您已经知道，有数百万 Visual C++ 开发者在使用、扩展和集成 MFC 和 ATL 到他们的应用程序中。事实上，高达 75% 的 Visual C++ 开发者使用 MFC。微软认为这些库非常健壮和成熟——它们已经存在了很长时间，曾作为数十万个应用程序的基础架构，并随着无数次更新和扩展而不断发展。它们非常成功。我们的重点正开始转向 .NET，但 MFC 和 ATL 将继续更新以保持与操作系统功能的同步，并将被维护到可预见的未来。像这些库的向后兼容性始终是一个问题，随着计算环境和需求的不断变化，扩展旧技术并仍保持健壮性变得越来越困难。现在是时候推出一款具有更长生命周期的新技术了，C++ 团队致力于让 MFC 开发者平稳、舒适地过渡。使用 Visual C++ .NET，您可以继续在有意义的地方使用 MFC 和 ATL，并按照您自己的节奏开始过渡到 .NET Framework。

2. 这些库在 .NET 愿景中扮演什么角色？

如今，MFC 和 ATL 填补了 .NET 中尚未完全实现的空白。.NET 拥有数千个类别的框架库，但它并未提供与 MFC 类似的应用程序框架功能。开发者需要了解他们的选择——无论是托管的还是非托管的，并仔细选择最适合任务的技术。Visual C++ 开发者通常非常高级，多年来一直习惯于为他们的应用程序选择合适的技术——所以这应该不是什么新鲜事。使用 .NET，VC++ 开发者拥有无缝集成现有非托管代码与更新的托管代码和数据这一独特优势，而无需担心失去向后兼容性或学习新语言的麻烦。C++ 的托管扩展对于推进应用程序非常有意义，而且易于使用。

3. 这些库将支持多久？

我们目前没有计划停止支持随 Visual C++ 一起发布的任何库。所有 VC++ 库在实际代码中都有极高的使用率，微软也不会忽视这一事实。我们将继续改进现有库，并计划随着技术的发展推出新库。

4. MFC 和 ATL 的新版本号和 DLL 名称是什么？

MFC 版本 7.0 - MFC70.DLL
ATL 版本 7.0 - ATL70.DLL

请注意与 6.0 版本 DLL 名称的变化——我们打破了二进制兼容性，以便对库本身进行一些关键性的改进。但您的代码在新版本下仍能正常重新编译。

5. 一旦 .NET 在每台运行 Windows 的 PC 上普及，是否还有任何理由编写 C++ 或 MFC 应用程序？

假设 .NET 和 MFC 之间存在功能对等，如果存在编写纯非托管代码的迫切需求，开发者可能会选择 MFC。开发者可能会选择使用 C++ 来定位 .NET，因为 C++ 语言拥有强大的、在其他地方找不到的特性，例如模板，以及编译器生成的代码质量。Visual C++ .NET 是唯一能生成高度优化的 MSIL 的 .NET 编译器，也是唯一能生成包含托管和非托管代码的程序集的编译器。当需要无限的灵活性和控制力时，开发者应该选择 C++。

6. 为什么开发者会选择使用 MFC 而不是 Windows Forms，以及为什么选择 Windows Forms 而不是 MFC？

Windows Forms 是一项技术，它尚未提供 MFC 中存在的命令路由和文档-视图基础架构。今天，选择 Windows Forms 类似于选择 Visual Basic 6.0 来替代 MFC。它们各自提供独特的优势——开发者或架构师必须确定哪些优先级是相关的。C++ 的真正优势在于，您可以同时选择 MFC 并将 .NET 技术集成到有意义的地方。我们这样做的原因之一是，它可以非常轻松地扩展现有应用程序，而无需重写它们。第二个原因是使 C++ 开发者能够自我设定采用 .NET 技术的速度。我们知道 C++ 开发者不会对强制放弃他们现有技能或代码的技术感兴趣。

7. 微软是否会用 MFC 编写任何应用程序，还是会开始转向 C# 和 Windows Forms？

微软的大部分应用程序已经在集成 .NET 技术，不仅使用 C#，还使用 C++ 和 Visual Basic .NET。未来微软在 MFC 上的开发可能会减少，但由于 MFC 是我们自己和第三方现有应用程序中如此多应用程序的组成部分——它将在一段时间内继续作为一个可行且受支持的框架。

8. WTL 的未来如何？它会被官方化为一个框架吗？

我们对 WTL 没有具体的计划。然而，我们对其日益增长的受欢迎程度感到非常惊讶，并密切关注着。这不是一个我们内部忽视的话题。

9. MFC 和 ATL 在内部进行了一些更改，但没有大的界面改动，并且只有少数几个新类。这是出于什么原因？

正如我所说，这些是成熟的库，能够很好地完成它们的任务。我们的目标是增强它们以跟上操作系统功能的步伐，在有意义的地方改进它们，并保持向后兼容性。我们为 Visual C++ .NET 所做的更新反映了这一定位，并包含了一系列改进，使这些库更易于使用、更安全，同时增加了对 Windows 2000 和 XP 的支持。

10. 您能简要介绍一下 Visual C++ 的新特性吗？

这个列表实际上很长——产品文档中有一个完整的“Visual C++ .NET 新特性”的枚举。我有几个我喜欢并且在自己的代码中用过的。这是第一次，在一个应用程序中同时使用 MFC 和 ATL 变得容易——编译器将不再抱怨头文件定义冲突。这两个库现在共享 CString，并且还共享其他几个非 CObject 派生的类。仅此一项特性就可以消除大量代码重复的可能性，并实现更优雅的实现。这早就该做了，而且很合理。STL 库已经彻底改进——源代码更易读，实现更快且符合标准，修复了所有已知的重大问题，如线程和跨 DLL 使用，并且，终于，有了全新的文档。当然，编译器本身也有大量的选项和新特性，包括全程序优化、代码安全特性（包括运行时缓冲区溢出检查支持），以及托管代码生成。

11. 我们是否可以期待 MFC 和 ATL/WTL 在不久的将来得到扩展，以涵盖 W2K、XP 和 CE 2002 中的新特性和控件？MFC 会尝试模仿 .NET 中的一些新组件吗？

是的，MFC 和 ATL 将继续支持开发者使用最新的 Windows 功能。如果您想在 MFC 应用程序中包含新的 .NET 功能，您可以直接做到——无需 MFC 来模拟这些功能。

12. 是否有任何工具可以帮助开发者从 MFC/ATL 迁移到 .NET？

除了 C++ 编译器的 /CLR 开关之外，没有。是否应该有？您希望它们做什么？它们应该如何工作？我们对此非常感兴趣，并热切希望获得关于此类工具重要性的反馈。

13. 我还能在 .NET 中使用 MFC 和我旧的 MFC 组件吗？

是的。很容易包装或扩展现有的 C++ 组件，使它们可以从 .NET 调用——任何语言都可以。这比以前使用 COM 和 ActiveX 要简单得多。只需添加一个关键字来标记一个对象为 .NET 引用类型，然后使用 /CLR 进行编译。无需 IDL，无需引用计数，无需注册代码。编写代码并使用它——非常简单。

14. MFC 和 ATL 是否会扩展以涵盖 XML Web 服务？

MFC 和 ATL 在 Visual C++ .NET 中已经具备了消费和暴露 XML Web 服务的能力，支持托管和非托管代码。

15. 各种向导有一些令人烦恼的地方，例如处理派生类不够好，或者过于严格。微软在 Visual Studio .NET 中如何解决这个问题？

我们在 Visual Studio .NET 中解决这个问题的一种方式是，首次公开了一个极其广泛的自动化接口，使开发者和第三方能够创建自己的插件应用程序。如果向导或功能不能满足您的需求，您可以自己编写。通过 VS.NET 自动化，您可以像微软的任何功能一样，在 IDE 中进行集成。如果您是 VSIP 计划的成员，您甚至可以将新的语言和编译器集成到 IDE 中。

16. MFC 是否会被移植到托管代码，以便在托管 C++ 中使用？

我们不太可能将 MFC 移植为完全托管的库。但是，完全可以将您自己的 MFC 应用程序扩展为托管代码——而无需离开 C++。

17. 是否会有一个类似于 MFC 的 .NET 框架？

.NET Framework 将继续发展，并可能添加 MFC 中已有的功能。C++ 团队正在内部推动实现这一目标——我们希望 .NET 成为 C++ 开发者一个有吸引力且舒适的地方。我们将通过几种方式实现这一目标。首先，我们将继续使在 C++ 代码中使用 .NET Framework 变得容易。其次，我们将确保继续使用 C++ 有其引人注目的理由——通过使 C++ 在 .NET 上实现其他语言无法达到的灵活性和控制水平。

18. 如果我无意编写托管代码，升级到 Visual Studio .NET 有哪些引人注目的理由？

产品的各个方面都有更新——IDE、调试器、编译器、库。正如我之前提到的，仅编译器就提供了多项新的优化和代码安全特性，提高了应用程序的健壮性。我们全面改进了 IntelliSense、调试场景，甚至是在构建代码时收到的警告和错误消息等功能。

底线：使用 Visual Studio .NET 构建现有代码将产生更快、更健壮的软件，并有大量新潜力来扩展您应用程序的功能，以适应新兴技术。

19. 我可以使用 Visual C++ .NET 开发传统的 MFC 应用程序吗？

当然！没有人强迫 VC++ 开发者完全接受 .NET——事实上，除了托管扩展之外，我们本迭代添加的大部分功能都面向非托管代码开发。通过改进的 IDE 集成、消息映射的编译时类型检查、ATL 支持以及访问新 OS 功能的类，MFC 开发比以往任何时候都更好。

20. 您最喜欢的网站是什么？

CodeProject.com。你们太棒了。