如何告诉vb6不要在每次创建dll时都创建一个新版本的interfaces/com对象？我有一个vb6com服务器（ActiveXDLL项目），每次我将更改放入vb6代码并生成dll时，.NET代码都会使用它，我还必须重新编译我的.NET客户端代码，因为它看起来像VB6的界面和com对象以生成新的GUID或版本。我承认这是一个很好的做法，因为进行了更改，但我想禁用此行为以在每次更新我的vb6dll时保持我的.NET客户端代码相同。无论对COM对象或COM接口做了什么更改，我如何才能告诉VB6保持所有GUID和ActiveXdll的版本相同？Project+Properties，Components选项卡中的选择很重要。您必须在此处选择“二进制兼容性”以强制它重新使用旧的GUID。并保留DLL的副本作为提供guid的“主”，将其签入源代码管理。当您添加新类时，您还必须更新该副本，以便将来的版本知道为这些添加的类重用相同的guid。容易忘记，很难诊断。这是非常危险的，重用guid是DLL地狱的一个非常强大的诱因。只要小心避免更改现有方法，就可以让旧的客户端程序继续使用新的DLL。不仅是它们的方法签名，还有它们的实现。遇到遗留DLL的更新客户端将以非常讨厌的方式失败，访问冲突崩溃几乎无法诊断。使用二进制兼容性只会让你买太多。接口兼容性的长期维护仅适用于非常简单的库，或者当您的接口从一开始就经过精心规划且面向未来时。查看某人的VB6库并看到成百上千的接口版本号（GUID和版本号都用于标识接口）可能会让人感到害怕，即使他们认为他们已经仔细管理了二进制兼容性。当你有一个共享库的程序系统时，情况会变得更糟。一项新要求甚至是错误修复可能需要对一个程序而不是12或20个其他程序的库界面进行重大更改。您必须通过明确的手动版本控制来适应这一点，您实际上更改了库的名称以反映具有一组全新GUID的新版本。通常这是通过编号完成的，因此像“FuddInvLib1.DalRoot”这样的ProgId可以与新的“FuddInvLib2.DalRoot”共存于两个具有完全不同的GUID集的库中：FuddInvLib1.dll和FuddInvLib2.dll。由于每个版本都出于支持目的而更改，因此您可以随着时间的推移在每个版本中维护二进制兼容版本，最终完全淘汰FuddInvLib1.dll。这当然意味着随着时间的推移迁移客户端代码以使用更新的库或库，但您可以按计划的速度进行升级。COM契约声明接口定义是不可变的（方法名称、参数列表、方法顺序、方法数量没有变化），但实现可以自由更改。天真，但真实。（VB二进制兼容性不允许您更改方法签名或接口中方法的顺序，尽管它允许您向它添加新方法-参见图表）。然而，正如Hans所解释的那样，在生产中对DLL的接口或其方法进行任何更改是“最糟糕的事情”，多年的DLLHell已经证明了这一点。通过版本更改保持二进制兼容性的一种方法是向组件添加新接口，并且在生成任何版本的DLL后永远（永远）不要接触旧接口。老客户会愉快地使用旧界面，而新客户可以使用新界面。使用旧接口错误的新客户端可以使用iUnknown.QueryInterface方法捕获它。在VB中，您可以这样做：IfNotTypeOfmyObjectReferenceIsmyNewInterfaceThen'优雅地处理错误EndIf如果引用了旧版本的DLL，这将调用QueryInterface方法并返回false。您可以通知用户他需要安装更新版本的DLL并退出。您可以将此功能包装到一个函数中，并在新客户端中初始化对象时调用它。如果不支持新接口，则说明您使用的是旧版本的DLL；您可以通知用户安装更新版本并从那里开始。以上就是C#学习教程：如何告诉vb6每次创建dll时不要创建新版本的interfaces/com对象？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
