非程序员最终用户创建在非托管c++中使用COM对象的c#插件的最佳选项
本文关键字：对象 COM 选项 最佳 插件 c++ 程序员 用户 创建 | 更新日期: 2023-09-27 18:24:28
我有一个遗留应用程序，它使用基于COM的非托管C++（MFC/ATL）来提供API，该API在历史上一直被visual basic脚本（偶尔也被C++dll）用于向主应用程序提供自定义对象和脚本扩展。最近，我们面临着允许用户在C#中创建加载项并通过dll加载它们的压力。这些外接程序中的功能范围包括一些内部计算以及将回调函数附加到主应用程序触发的COM事件。
我知道，创建可以从非托管C++中使用的C#加载项的最简单（可能更符合逻辑）的方法是使用COM互操作，但我们不希望编写加载项的最终用户必须管理COM代码等。由于加载项不创建任何新的COM类，而只是使用主应用程序提供的类，我想找到一个让C#模块尽可能简单的解决方案。为此，我正在考虑一个位于非托管应用程序和C#插件之间的C++/CLI包装器。
（1） 根据我的要求，这有必要吗？有没有一种更简单的方法可以加载只订阅非托管代码中COM事件的c#dll？
（2） C++/CLI包装器听起来是为最终用户提供最简单解决方案的最佳方式吗？
任何帮助或解释都将不胜感激。。。我目前正在学习《.Net and Com:The Complete Interoperability Guide》，但要同时学习的内容很多。此外，我知道这个问题在许多其他问题中引用了重复的信息，但我找不到以前任何涉及这个特定最终用户问题的问题。
更新：我可能已经指定了在主应用程序二进制文件中导出类型库，并且我已经能够创建一个C#可执行文件，该文件可以实例化.net对象并附加到COM事件。我需要了解的是如何对类库（dll）做同样的事情。对于C++dll，我们调用LoadLibrary，并在dll中提供一个执行所有静态初始化的入口点，但我不知道如何使用C#进行初始化，我的理解是，除非非托管应用程序使用前面提到的方法之一引导CLR，否则这是不可能的。希望我只是被误导了，这比我想象的要容易得多？
解决方案实际上取决于交互的方向。
对于使用事件，您可以创建一个C#项目，该项目通过RCW与非托管组件通信，并简化了连接事件的过程。但是，如果您需要让非托管组件调用第三方组件函数，这将变得更加复杂。在这种情况下，您可能需要修改非托管组件以调用托管模块（再次通过COM互操作），但需要构建这些组件以通过COM互操导出接口。
不过，有相当多的COM互操作"gotchas"。作为一个建议，考虑将您的托管互操作组件放入COM+应用程序中，这样它们可能会耗尽进程；这并非没有额外的复杂性，但它可以帮助防止.NET版本控制、32/64位问题、进程状态等方面的各种问题。
最后，我看不出有什么特别的理由使用C++/CLI（而不是C#），除非您对它更熟悉。一旦您将COM互操作作为通信机制，托管组件的语言就无关紧要了。
希望能有所帮助。。。这是一个复杂的技术领域，所以这将是一些工作（我已经做过几次了）。