编译activex控件时，工程兼容与二进制兼容的本质区别是什么呀？

Question

编译activex控件时，工程兼容与二进制兼容的本质区别是什么呀？
查了些资料，还是不明白。
可能是专业术语我不懂吧。我只想明白。
1。哪种情况下要用工程兼容编译，哪种情况下要用二进制编译。
2。我的dll已经发布到客户的机器上了，但是我修改后重新编译了，然后将这个dll覆盖客户老版本的dll，是不是覆盖一下就行了，是不是需要重新注册呀，我在测试中发现，有时要重新注册，有时不重新注册就行，我没找到原因。为什么有时必须注册，可有时覆盖一下就行而不用注册

Answer 1

我测试了一下，发现如果用工程兼容编译，也不用重新注册，不过调用它的exe文件也必须重新编译才行。
应算重新注册dll,不重新编译exe也是不行的。

Answer 2

Tiger_Zhao(VB老鸟) 说的不准确
主要是你对你的Com变动的范围。
如果只是修改了过程与函数内部的处理，可以使用二进制兼容，并且直接替换原来的com即可。
不过如果你增加了公开接口，或者修改了公开接口的参数个数、类型以及返回值类型，就是你想二进制兼容编译的时候VB也会提示你兼容性中断的。另外说一个窍门：
-----------------------
第一次编译之前尽量将各个公开接口定义周详。
为防止遗漏（遗漏几乎是必然的），增加一下接口：
public function Command(byval CommandString as string) as string
编译，然后选择二进制兼容。以后如果需要增加新的接口，调用Command，传入不同的参数即可。
然后Com中再增加都是私有的函数和过程。
通过这种方式可以有效防止DLL炼狱的煎熬。

Answer 3

用好二进制兼容前提不要更改公共接口定义，我前面的说的是比较模糊，应为变动的情况有好多种，影响不一样。所以比较适合维护阶段仅对内部代码进行修改的情况。一开始设计的接口不可能一成不变的，有时打破二进制兼容是必须的。
采用 CommandString 的方式是不可取的，接口不直接明了，需要依赖文档描述，而且本来可以用编译器发现的类型或参数不匹配的错误必须在函数中进行判断，工作量的增加远远超过打破二进制兼容进行重新编译。

Answer 4

我还是有点不明白,如果公共接口改了,那么只是与调用它的exe文件发生关系呀,按理说也不用重新注册呀,因为注册只是注册一个clsid呀,是吗?

Answer 5

接口变了，TypeLib 的版本就不一样，GUID 也需要重新分配，只不过会尽量保持两个版本的兼容。

Answer 6

只要你编译为 dll了 ， 就应该设置为 二进制 。 如果从来没有编译过 ， 处在调试时期 ， 就设置为工程兼容就可以了。