最近，这个主题已经出现在了“新闻组”里（呃，至少已经出现在了很多blog里），我一直在考虑如何回复大家……但事实上，我根本没有回复的必要，因为Dave Totzke已经替我这么做了。他在文中提到了一点：我们应该让C++继续存在下去，是因为Office是用C++写成的……关于这点我不太敢恭维，因为这理由实际上应当是——这个被托管的世界无法取代我们为底层的硬件和操作系统编写本地代码的需要。我们至少需要一种方案，使图形软件、设备驱动器、网络信息过滤器等等都能高效地运作……因此，我们还是需要非托管的C++。但对于VB6的变革而言，就没有类似的需要了。
确实，升级复杂的代码库是件相当困难的事，但是安装VB.NET并不意味着你必须删除VB6。你可以保持你现有的代码库，而在.NET里编写新的代码，然后在必要的时候让这两个世界互相运作。在MSDN里，你可以找到一个Access应用程序，当你点击某些特定的按钮时，它会弹出新窗体来……你也可以找到为Outlook和Word写的基于VB6的插件，其实它们就是.NET代码的包装材料，是个VB6代码和VB.NET代码的混合品。
还有很多东西，它们可以在VB6里找到，却没有被包含在VB.NET里，我觉得这样不太好，但我想，它们可以通过.NET组件、ActiveX组件、或者是Visual Studio插件的形式引入VB.NET。譬如说DDE（动态数据交换，涕淌注）吧，它本身并不是.NET框架的一部分，因此，我设想如果能有一个小组件，使我们在.NET中能直接访问DDE，在新数据到达时能够引发事件，诸如此类的……那就好多了。我真希望人们能致力于构建（或者是致力于请求构建）这样的组件，而不是拼命叫嚣着做某某事不是个好主意。至少至少，人们也应该努力使它被列进升级开发的进程中。我们最好能让某个人来构建这样的一个工具，这个工具不仅仅是一个向导，而是能胜任升级的工作，并且包含了一大堆附加的库，藉此来转换旧的代码。这将会是个浩大的工程，但是比起对VB6做一些补充性的改进而言，它的成果会更令人满意的。
顺便提一句，我一直都想告诉大家，我真的认为，.NET世界中至今仍然缺少了一些东西。我们需要为.NET提供一个类似 Access界面那样的工具……它不能像VB6里的那个工具，因为它对于我眼中的开发人员的水平而言，实在是太难用了……它应该是一个支持数据库拖放的应用程序创建工具，像Access、FileMaker Pro、Hypercard，等等那样的……它应该能在这些设置背后自动生成.NET代码，这样，我们就可以使用这个工具，配合着由VB.NET或C#创建的代码，来扩展简单的应用程序。我想我会给它起个名字，Access.NET :)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
以下是原文供网友们参考，如果大家要到Duncan先生的主页上读文，请点击这里。
This topic has been in the 'news' lately (well, at least in the blogs) and I've been considering replying.... but it turns out I don't have to, because Dave Totzke has done it for me. I don't really agree with his comment that we've kept C++ alive because Office is written in it... it is actually because the managed world doesn't replace the need to write native code against the underlying hardware and OS. We need to have at least one avenue for folks to write the high-performance graphic software, device drivers, network packet filters, etc.... so we need unmanaged C++ to stay. There isn't a similar need for new development on VB6.
Yes, it is hard to upgrade complex code bases, but when you install VB.NET it doesn't uninstall your copy of VB6. It is possible to maintain an existing code base while you write new code in .NET and then interop as necessary between the two worlds. Within MSDN, we have Access applications that pop-up Windows Forms when you click certain buttons... we have VB6-based add-ins for Outlook and Word that are simple wrappers around .NET code and some that are a mix of VB6 code and VB.NET code...
There are some things that were in VB6 and are not available in VB.NET that I feel still need to be available, but I think they could be made available as .NET components, ActiveX components, or add-ins to Visual Studio. Take DDE for example, it just isn't part of the .NET Framework, so I think it would be nice if we had a small component that allowed me to access DDE from within .NET, fired events when new data arrived, etc... I wish that people would put their effort towards building/requesting these types of components instead of advocating something that just isn't a good idea. At the very least, push for more effort to be put into the upgrade process, lets get someone to build more than just a wizard, build a tool that does the upgrade and includes a ton of additional libraries to help with transitioning older code. That would be a lot of work, but the end result is still better than just doing incremental development on VB6.
By the way, this is as good of time as any to point out that I do believe that there is something missing in the .NET world right now. We need an Access-like tool for .NET... not what VB6 was, which was really much too complicated for the level of developer I'm thinking of... but something that is a drag-and-drop database form focused application creation tool. Like Access, Filemaker Pro, Hypercard, etc... but producing .NET code behind the scenes so that you can extend simple applications created using this tool with code produced out of VB.NET/C#. I think I'll call it Access.NET :)
