VB中如何设定COM组件和ActiveX控件的CLSID值

最新推荐文章于 2021-01-22 12:25:58 发布

collin1211

最新推荐文章于 2021-01-22 12:25:58 发布

阅读量2k

点赞数

分类专栏： VB 文章标签： vb interface 算法测试

本文链接：https://blog.csdn.net/collin1211/article/details/2963240

版权

本文介绍了在VB中如何设置COM组件和ActiveX控件的CLSID值，探讨了VB的版本兼容性设置对CLSID的影响，包括No Compatibility、Project Compatibility和Binary Compatibility三种模式，并讨论了当失去原有OCX文件时的处理方法，以及建议使用ProgID进行引用以降低依赖性。

摘要由CSDN通过智能技术生成

   此问题以前一直没有碰到过，因为VB建立的COM和ActiveX的工程，都是超级智能，什么都封装好了，连组件注册都帮你弄好了，而且VB没有提供入口来修改这些属性。
    以前用VB建立这类工程，不需要关心这些细节，也没碰到过什么问题，因为的确，CLSID都是自动生成，不需要人为干涉。直到今天去上海大平洋保险出差，遇到金蝶OA系统的一个问题：编设出来的组件CLSID和已经布署的系统的CLSID不一样！
    这下就出问题了，因为在完成测试新编译出来的组件之前，我们不能把新改的组件布署上去（反正原因很复杂……）。最后是没办法，只好研究一下VB中是如何设置组件的CLSID的。
    第一感觉就是VB建立工程的时候，用随机算法算出一组CLSID，然后存在某个地方，因为只有这样，每次编译时，才能保证同一组CLSID。但是把工程目录搜索了一遍，包括ASCII和二进制搜索，都搜不出来，挨个挨个文件看也看不出。
    只好研究VB的工程相关设置，也没发现，最后觉得有点令人怀疑的地方是所谓的Version Compatiblity（“版本兼容”）。研究后终于搞清楚了其中来龙去脉。

    VB的兼容卡中有三个设置：
1、No Compatibility：不兼容，此设置下，每次编译出的CoClass和Interface的CLSID都会不一样。
2、Project Compatibility：工程兼容，此设置下，每次编译出的CoClass的CLSID一样，但Interface的CLSID不一样。
3、Binary Compati