VB6和.NET之间的互操作是否可行？
我正在开发一个与一些.NET程序集交互的VB6应用程序，但“冷启动”和其他内聚问题的组合会导致不平滑的结果。
答案 0 :(得分：6)
编辑 - 稍微缩小了我的答案。
有可能吗？是的，当然。
我会推荐它吗？当然不是！
陈规定型的情况（我遇到过很多次）是你有五年或十年前用VB6编写的一些组件。作者已离开公司，虽然应用程序解决的问题相当简单且易于理解，但应用程序本身并非如此;公司里没有人真正知道如何维护它和/或它写得很差而且难以维护。
如果您的情况如此，那么我会建议一个端口 - 特别是如果您的公司缺乏VB6资源并且拥有大量的.NET资源。正如MarkJ所说，这不一定是普遍意见，但它与我自己的经验一致。
在： -
处理MS帖子http://msdn.microsoft.com/en-gb/dd408373.aspx#migrate3
MS说，从头开始重写通常比扩展或自动迁移（使用链接的工具）更昂贵。我当然使用Visual Basic升级向导来获得一个起点，虽然我们通常移植到C＃而不是VB.NET。这是一个很好的起点 - 特别是如果你偏爱VB.NET。
最后： -
通常我们只会针对少数情况推荐[重写]，包括：
- 原始申请有很多 坏的问题 架构，设计和/或编码 实践。症状可能包括不良 可扩展性或性能，用户差 界面和困难 维护代码。
- 原作 申请不再匹配 重要的业务需求 区域。需要进行核心更改，例如 必须交付用户界面 通过浏览器而不是智能 客户端。
- 公司已有 .NET的重要技能得到了提升 其他应用程序和应用程序 很好理解和相对 小。
- 不再有源代码 适用于重要部分 应用
这些都是优点，但如果您无法在项目中找出至少一个问题 - 应用程序运行正常且可维护，您需要进行的更改很小，公司有大量的VB6资源，你可以访问源代码 - 我可能会问你为什么要迁移到.NET。在我参与的每个相关项目中，我们遇到了前三个问题中的两个（如果不是全部三个）。
如果移植根本不是一个选项，那么我们需要更多信息。它是什么类型的应用程序？什么是VB6在做什么？什么是.NET？
答案 1 :(得分：4)
我们有一个大型项目，我们在5年前开始添加.NET功能，并且它一直运行良好。最初我们只是添加非可视组件，慢慢将业务逻辑移动到.NET中有很多原因：
.NET组件（用C＃编写）如此成功，我们开始用C＃编写可视组件（使用interop toolkit和C# Interop toolkit），甚至WPF组件。这里的事情有点粗略，有时有三个消息泵，3个技术堆栈的组件导致奇怪（组件从屏幕上消失或没有正确地重新压缩）和野蛮黑客（sendMessage到特定组件，LockWindowUpdate在这里和那里）把事情搞定。然而，对于我们大多数客户认为是用WPF编写的APP，它赢得了无数的行业奖项，并且每天都被成千上万的客户使用，这是对VB6的弹性（即使令人难以置信的痛苦）以及如何很好的微软创建的Com / .NET互操作故事（哎呀Visual Studio 2010几乎是同一个Franken怪物，它只是C ++ Com / C＃/和WPF）。
答案 2 :(得分：3)
VB6和.NET之间的互操作是否可行？
如果你强调“策略”这个词，那么我必须强烈建议，“不！”策略将描述您的正常或预期的攻击计划，并且将.Net与vb6混合不是在这种情况下成功的秘诀。这有几个原因，包括寻找对较旧的vb6工具的支持，vb6运行时不再为我的微软提供服务，随着时间的推移越来越难找到训练有素的vb6开发人员，需要找到了解两个平台的开发人员。 .. 我可以继续下去。关键是你不想在大多数时候都这样做。
但是让我们改变一下你的措辞：
VB6和.NET之间的Interop是一个可行的开发选项吗？
啊，那更好。当你发现自己正处于一些现有的vb6代码中，或者你有一个经验丰富的vb6程序员，需要一些时间来熟练掌握.Net时，这对于有限的持续时间来说是一个可行的选择解决手头的情况。如果你可以将它与.Net 4.0结合使用，尤其如此.Net 4.0具有一些功能，可以使它更容易。
只是不要将其作为整体战略的一部分。
答案 3 :(得分：2)
VB6和.NET之间的互操作绝对可行（虽然不可取）。
在我们的情况下，我们有一个包含多个模块的遗留GIS应用程序。我们已经能够将GIS部分移动到.NET中并使用互操作来使用现有代码。
用C＃重写旧的VB6代码需要几年时间，因为我们无法告诉用户等待那么久（我们的合同只运行了一年然后再续订），Interop一直是最好的解决方案。这样，我们可以继续支持现有（工作）代码，同时逐步重写模块，同时引入新功能（用C＃编写）。
话虽如此，我不得不承认这不是一项微不足道的任务。我们必须使用旧的VB6应用程序exe并将其更改为我们的.NET代码引用的ActiveX exe，同时我们的VB6代码通过Interop引用其他一些.NET代码。有些日子，我很惊讶我们所做的工作，但它确实如此，而且很好！
但是，如果我有无限的金钱和时间，我会避免Interop，就像它是ghonnosyphiherpilitis。
答案 4 :(得分：0)
VB6和.NET之间的互操作是否可行？
仅在您有一些无法迁移的现有非托管代码的情况下。但是在VB6上编写新代码是不可行的。
答案 5 :(得分：0)
我认为使用VB6 COM组件的.NET应用程序在某些情况下是可行的。
作为一个例子，我有一个.NET应用程序需要对Office文档进行一些相当复杂的操作。这在.NET中很难实现，就好像你在发布引用时不是非常小心一样，Office应用程序将无法按照this KB article中的描述退出。
在这种情况下，一个实用的解决方案是创建一个封装了所有Office操作的VB6组件，向调用者公开一个简化的API，而不使用任何Office对象模型。
答案 6 :(得分：0)
Craig不是在谈论从.NET调用COM，他在谈论
“与某些.NET程序集交互的 VB6应用程序”
在这种情况下，可行性问题的答案不可避免地是“不”。
在短期内，您正在处理各种已知和未知的运行时挑战 - 您所谓的“内聚问题”是由托管和非托管环境中的细微差异以及互操作的限制引起的。您还提到了部署方面的挑战。即使在开发阶段，我们都知道COM组件看起来像.NET调试器的黑盒子。在许多情况下可以创建和调用CCW，但并非总是如此，并且在降低生产率和技术复杂性方面会产生影响。
真正的可行性损失是，从长远来看，VB6应用程序将开始显示自己的一系列问题。技术世界正在缓慢但肯定地落后于VB6。自愿和有能力的VB6开发人员的供应正在萎缩，最终VB6 / COM应用程序将在开发，部署和运营方面遇到不兼容和其他缺陷。最终VB6应用程序将以各种方式失败，很难找到有关如何及时修复它们的信息和资源。这对我来说听起来不可行。
将VB6应用程序带到.NET（并最大限度地减少从应用程序层直接使用COM）;你会很高兴的。我还发现，当你采用一种平衡手动工作和自动转换的方法而不是坚持你必须完全忽略遗留代码并从头开始做所有事情时，可以更有效地重写.NET的大型VB6 / ASP.COM应用程序。 ”。