我在拥有大量用户安装基础的大型代码库上工作。该代码最初是用 vb6 编写的，带有一些用于低级工作的 c++ COM 模块。
重写所有已经用 vb6 编写并且我们的客户每天都在使用的代码是完全不可行的，但我们也在继续对软件（大小）进行改进和定制。
到目前为止，我的解决方案是用 c#（现在的 winforms 甚至 wpf）编写大部分新代码，然后使用 COM 互操作从 vb6 调用模块。
有没有人有像这样的长期软件套件（10 年以上）的经验，不能停止完全重写，但同时需要不断的新开发。此外，在这样的混合系统中，连接模块的最佳方式是什么？我现在正在使用 COM，但也考虑过具有单独进程的 IPC。
很难给出一个包罗万象的答案，但高层次的方法是明确的。至少，这是我使用的方法。优先考虑您的目标，然后尝试确定实现这些目标的成本。您的成本基本上归结为“开发人员时间”。
首先，你希望任何正在工作的东西都能继续工作。如果你有一些正在工作的东西，并且没有充分的理由重写它，那就保留它。
如果您的某些现有代码需要更新才能完成其工作，那么您正在考虑维护成本。此时，您需要确定重写是否会提高维护成本，使其值得。不要忘记减去新错误的测试和调试，因为会有新错误。不要仅仅因为它是旧的而忽略工作代码。
如果您现有的代码是足够模块化的，您通常可以一次一点地修改它。首先重写高维护组件。
如果您将在 C# 中进行新的开发，那么您应该可以很好地使用 COM 组件，直到您有足够的理由来替换它们。
我认为你有一个很好的计划。这最终会将大部分代码移动到 C# 中，从而利用更好的工具集。
VB6 代码是否包含 COM 对象？
您提到代码“无法完全重写”。但你不必停下来。您可以用等效的 C# 代码逐一替换 VB6 的每一项功能。这将允许您一次进行一项更改（最好使用自动化测试来证明您没有破坏任何东西）。
当有激励因素时，根据需要重新编写。
我从事的一个旧 Windows 项目有一个用 C 语言编写的规则引擎，它正在工作，所以我们只是把它作为一个黑盒 DLL。
我们构建了一个新的前端，用户群对应用程序易于使用的新现代外观印象深刻。内部结构并没有真正改变。
数据库访问层使用 SQL Server DBLIB，直到我们升级 SQL Server 才重新编写。
我们有几个这样的系统。这一切中令人不安的部分是VB6 的生命周期支持状态。有一个风险（无论多么小），您将无法从 Microsoft 获得帮助解决诸如未来服务器升级等令人瞩目的问题，并且无法自行修复（例如，由于VB6 DLL 和修补的服务器 O/S）。这是您的管理层可能感兴趣的风险——但是，如果您现在没有任何支持协议，也许他们对此感到满意？
我们实际上正在考虑重写和重新设计一些更关键的部分。我们已经尝试过渐进式进化，它可以工作，但会导致（让我们说）有趣的操作和维护情况。我强烈建议您使用大量可配置的日志记录来检测所有内容（旧代码和新代码），如果您还没有的话，以帮助进行故障隔离。
COM 听起来像是旧版和新版之间的合理接口。除非您在组件之间进行非常简单的交互，否则我真的不明白您为什么要回到更基本的 IPC 机制。COM 有其复杂性，但它也提供了许多有用的抽象，例如数据类型和版本控制，您必须重新发明和维护......
我认为您需要为您的客户查看升级路径。事实是，当他们拥有 16 个核心 CPU 时，您会希望通过并发来加快速度。因此，您有一个业务案例可以从 VB6 转向 WCF。WCF 内置了并发和同步支持。它可用于本地进程内通信以及跨进程和跨机器通信。它还具有允许您进行更多 AOP 风格编程的好处。
我目前是开发大型遗留系统的几个开发人员之一，该系统最初是 C 和 C++ 与 Win32 的组合，后来是 MFC，在后端 C 代码中有少量汇编。我们最近从 VC++ 6 跳到 Visual Studio 2005（并且已经升级到 2008），以获得我们正在处理的项目的最新版本。自 IDE/编译器升级以来，我们一直在清理一些外观和感觉，并添加了带有 WinForms 的托管 C++，现在添加了带有 WCF 的 C#。
虽然我们系统的基础（包括后端）几乎肯定会保留在 C 中（至少在可预见的将来），但前端中的任何新内容很可能会在 C#/WCF 中完成。当我们有时间和/或需要时，我们打算开始用等效的 C#/WCF 代码替换前端的旧部分。