1、如果你生成的DLL文件被其他程序所直接引用(即在工程菜单里选择引用)的话,则必须使用兼容方式。如果是被其他程序间接引用(即其他程序使用到此类时只是定义为object,使用createobject方式创建类实例或由外部传入类实例),则可选择不兼容。
2、如果当前还未编译为dll文件,你的dll文件源代码和引用该类的工程源代码在一个工程组中,则可使用工程兼容方式。
3、如果你的Class已编译为dll文件,且被其他程序所直接引用则必须使用二进制兼容(如果不使用这种方式的话,当你的Class重新编译后,你的所有引用到该dll的程序均需要重新编译)。二进制兼容方式是要求最严格的一种。使用该方式一定要注意:A、所选择的与之二进制兼容的文件一定是能够满足引用该DLL文件的程序正常使用的。B、不能改动原有CLASS的公有接口,如公有属性名、属性类型、方法名、返回类型、参数及参数类型等(可新增属性或方法),一旦对程序的改动造成与原编译的DLL文件不能二进制兼容则所有引用到该DLL的程序均要重新编译方能正常使用。

解决方案 »

  1.   

    haor,您的意思是否指“原有CLASS的公有接口,如公有属性名、属性类型、方法名、返回类型、参数及参数类型”改变就一定要对DLL重新注册,但如果就单是改变方法内的程序代码,重新生成DLL后不用重新注册(REGSVR32.EXE)
    例如:
    public function addrecord(no as integer,name as string) as long 
                        //若改变一点也要重新注册该DLL
    {
    ....    //若改变可以重新生成DLL便可,不用REGSVR32该DLL
    }
    恳请回答,谢谢。
      

  2.   

    以COM而言, 任何"公有属性名、属性类型、方法名、返回类型、参数及参数类型" 改变都不能在原来的interface上. 所以每次改变都需要生成新的interface.1. 如果client端是scripting client, 也就是ASP, VB的话. 三种兼容模式都可以. 因为它们都是late-binding的.2. 如果client端是基于v-table来访问server的话(比如说VC), 就要用二进制兼容.user-defined interface(使用IDL定义interface并compile进type library)在较大系统开发或interface经常变化时较好.但由于VB programmer通常不会用user-define interface, 所以把软件放到production server上时要, 同时升级client, server端.
      

  3.   

    我的意思不是说改变class的公有接口后就要对DLL重新注册(编译后会自动注册)。而是说对该DLL引用的程序不用重新编译。
    如果改变公有接口导致不能二进制兼容后,即使你再使用regsvr32重新注册,原有引用该dll的程序仍然不能正常使用。
    改变方法内部的代码不会影响兼容性问题。
      

  4.   

    See the following...
    ========================Know When to Set Binary CompatibilityCompiling a DLL specifying Binary Compatibility means that the newly generated DLL will have the same TypeLibraryID, Class IDs, Interface IDs, and other identifiers as the old one. This is required once subsequent versions of a DLL are deployed to working clients. However, its use during the development cycle may be detrimental to productivity. Keep Project Compatibility until you are willing to freeze all interfaces, then go with Binary Compatibility and stick with it.More InformationCOM rules state interfaces cannot be changed if they keep their IID. Visual Basic uses a feature of COM known as interface forwarding to shield developers from this rule. However, this ends up creating complex registry entries. This forwarding is in reality a chain of lookups that eventually points to the latest and greatest compiled COM component.The ability to drop a component into MTS is lost once the forwarding chain is set. This can cause confusion when you are in the midst of a rapidly changing interface specification. Eliminate as much of this chain as possible.
    In addition, there is an application cycle issue. Once interfaces have been set, going back and changing them may put other concurrent development activities at risk. How ToDuring development cycle, your object interfaces are usually undergoing many changes required to correct errors not detected during the design phase. During this time of evolution, it is wise to maintain your DLL with project compatibility. In extreme cases, you might even rely on late binding. This, however, will take away the huge developer performance benefit of the Visual Basic IntelliSense AutoComplete feature. You might want to take a step back, get your interfaces right, and then resume with concurrent development.
    Once you are certain you can roll out the component, store a separate copy of your DLL in a centralized agreed upon location for future reference (perhaps in Visual SourceSafe with Read Only Permissions), point your Compatibility dialog to it, and specify binary compatibility.
      

  5.   

    真是太感谢Haor和GoldenLion两位高手的帮助,我已经明白了90%,剩下的就靠自己不断实践去领悟了,THANK YOU,YOU ARE WONDERFUL!!!
      

  6.   

    hmm...给分!!
    其实我不是高手,只是在实际使用中的时候碰巧碰到了兼容性问题所以仔细研究了一下,凭我的使用经验来回答你的问题的。GoldenLion才是真正的高手,我有些问题还正在向他请教呢。:)
      

  7.   

    两位高手,可不可以继续解答在下的另一条问题("又有关于ACTIVEX DLL的问题,挺有深度和实际实践意义的"),不胜感激。