使用VB6做部分功能重叠的多个com组件会带来dll hell吗？

[y2012]

本人VB小白接触vb时间不长，服务器上运行多个系统，每个系统的核心业务逻辑我想用VB6开发，封装在各自的activex dll中，因为这些dll中有些类和代码是重叠的，最终都要在同一台电脑上注册。这样会带来dll hell吗？如果是这样，是不是不采用activex dll这种方式，而是把每个系统的代码放在一个工程里面，最终生成一个exe文件就不会带来dll hell的问题？

[脆皮大雪糕]

我负责的项目曾经因为兼容出现过大问题，下面是血泪总结。 首先，工程要设置对编译结果的二进制兼容，或者对项目进行兼容。 其次，代码上要进行兼容，简单的说就是 1、所有原来是public的东西，都不能删掉，即使作废了，函数声明也留着 2、所有原来public的函数，参数只能往后面加可选参数，原来已经暴露了的参数名字、数据类型、顺序都别改。 最后，dll不断的用新版本迭代演进，一旦发生新增public函数或者某个public函数新增，那么新版本覆盖旧版本并完成注册以后，就严禁再拿旧版本来注册了。 当时出了事，解决完了我还专门写了个程序来比较编译好的dll暴露出来的接口是否和旧版本的兼容，并且项目组成员统一编码规范。说多了都是泪

[y2012]

引用 1 楼 chewinggum 的回复:

我负责的项目曾经因为兼容出现过大问题，下面是血泪总结。 首先，工程要设置对编译结果的二进制兼容，或者对项目进行兼容。 其次，代码上要进行兼容，简单的说就是 1、所有原来是public的东西，都不能删掉，即使作废了，函数声明也留着 2、所有原来public的函数，参数只能往后面加可选参数，原来已经暴露了的参数名字、数据类型、顺序都别改。 最后，dll不断的用新版本迭代演进，一旦发生新增public函数或者某个public函数新增，那么新版本覆盖旧版本并完成注册以后，就严禁再拿旧版本来注册了。 当时出了事，解决完了我还专门写了个程序来比较编译好的dll暴露出来的接口是否和旧版本的兼容，并且项目组成员统一编码规范。说多了都是泪

谢谢楼上的解答，我受益匪浅。

[y2012]

如果我的代码不做成dll，而是直接编译成一个exe文件，是不是就没有上面说的问题？@脆皮大雪糕

[y2012]

VB6生成的dll在C#中调用也没有这样的问题？@脆皮大雪糕

[脆皮大雪糕]

全部业务逻辑都内嵌在exe里面绝对没问题，但是程序升级的时候就必须整体升级咯，com的设计初衷是一个dll可以共享给其他应用，正常情况下，只要接口兼容，新的dll可以放到任意位置并注册，调用它的exe不用重新编译也不用改变任何设置就能够继续使用。非com的dll就要放到指定的位置或者系统设置path。各有利弊吧，最后微软自己都有点受不了了。

[y2012]

引用 5 楼 chewinggum 的回复:

全部业务逻辑都内嵌在exe里面绝对没问题，但是程序升级的时候就必须整体升级咯，com的设计初衷是一个dll可以共享给其他应用，正常情况下，只要接口兼容，新的dll可以放到任意位置并注册，调用它的exe不用重新编译也不用改变任何设置就能够继续使用。非com的dll就要放到指定的位置或者系统设置path。各有利弊吧，最后微软自己都有点受不了了。

明白了，我决定抛弃dll了。

[舉杯邀明月]

如果能“不采用ActiveX DLL”，那应该是最好的了。 这样，各个工程的DLL直接放在各自的“工程目录”中，就算是DLL名字相同，也不会相互影响。 如果是ActiveX DLL的话，因为需要“注册”，同名的DLL不兼容，必然引起问题。 如果只能用AcitveX DLL来实现，那么 脆皮大雪糕 在1楼中说的就是很重要的东西了。 另外楼主可以参考一下这篇BLOG：DLL Hell(DLL地狱)问题

[舉杯邀明月]

引用 6 楼 Y2012 的回复:

[quote=引用 5 楼 chewinggum 的回复:] 全部业务逻辑都内嵌在exe里面绝对没问题，但是程序升级的时候就必须整体升级咯，com的设计初衷是一个dll可以共享给其他应用，正常情况下，只要接口兼容，新的dll可以放到任意位置并注册，调用它的exe不用重新编译也不用改变任何设置就能够继续使用。非com的dll就要放到指定的位置或者系统设置path。各有利弊吧，最后微软自己都有点受不了了。

明白了，我决定抛弃dll了。[/quote] 抛弃dll？ 　好主意啊…………

[y2012]

引用 7 楼 Chen8013 的回复:

如果能“不采用ActiveX DLL”，那应该是最好的了。 这样，各个工程的DLL直接放在各自的“工程目录”中，就算是DLL名字相同，也不会相互影响。 如果是ActiveX DLL的话，因为需要“注册”，同名的DLL不兼容，必然引起问题。 如果只能用AcitveX DLL来实现，那么 脆皮大雪糕 在1楼中说的就是很重要的东西了。 另外楼主可以参考一下这篇BLOG：DLL Hell(DLL地狱)问题

太感谢了

[y2012]

引用 8 楼 Chen8013 的回复:

[quote=引用 6 楼 Y2012 的回复:] [quote=引用 5 楼 chewinggum 的回复:] 全部业务逻辑都内嵌在exe里面绝对没问题，但是程序升级的时候就必须整体升级咯，com的设计初衷是一个dll可以共享给其他应用，正常情况下，只要接口兼容，新的dll可以放到任意位置并注册，调用它的exe不用重新编译也不用改变任何设置就能够继续使用。非com的dll就要放到指定的位置或者系统设置path。各有利弊吧，最后微软自己都有点受不了了。

明白了，我决定抛弃dll了。[/quote] 抛弃dll？ 　好主意啊………… [/quote] 完全抛弃是不可能的，我使用一些标准的dll，比如ado的dll，opc的dll，但是自己不创建activex dll.把自己创建的所有dll都放在项目中。应该就OK了哈哈。

[舉杯邀明月]

引用 10 楼 Y2012 的回复:

. . . . . . . . . . . 完全抛弃是不可能的，我使用一些标准的dll，比如ado的dll，opc的dll，但是自己不创建activex dll.把自己创建的所有dll都放在项目中。应该就OK了哈哈。

如果你用VB6写程序，“绝对抛弃dll”显然是不现实的，至少MSVB6VMM.dll就是一个“无法摆脱的噩梦”。 我上面说的也并不是说完全的不用任何dll，只是说“不要自己编写dll，再引入到工程中”。 尤其是VB6的“原生态”只支持ActiveX DLL，这个其实很烦人…… 不过我自己写了个工具，可以用VB6编写“标准DLL”了。 只是这个“应用门槛”比写ActiveX DLL高一些，所以最好也不要轻易用。

[舉杯邀明月]

自从前几年我的“标准DLL编译工具”出来之后，我再也没有使用VB6来编译AcitveX DLL了。 不过还在“酝酿中”的一个VB6插件，以后开发时也只能写成AcitveX DLL的。 （Add-In插件只能是ActiveX DLL，这个没得选……）

[y2012]

我接触VB6的时间还不长，我以前是写C#的，只能在使用中慢慢体会了。

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

[冰不孤独]

引用 12 楼 Chen8013 的回复:

自从前几年我的“标准DLL编译工具”出来之后，我再也没有使用VB6来编译AcitveX DLL了。 不过还在“酝酿中”的一个VB6插件，以后开发时也只能写成AcitveX DLL的。 （Add-In插件只能是ActiveX DLL，这个没得选……）

我也一直在用你的DLL编译工具.在做ERP 了!

[冰不孤独]

引用 15 楼 oBingBuGuDu 的回复:

[quote=引用 12 楼 Chen8013 的回复:]
自从前几年我的“标准DLL编译工具”出来之后，我再也没有使用VB6来编译AcitveX DLL了。


不过还在“酝酿中”的一个VB6插件，以后开发时也只能写成AcitveX DLL的。
（Add-In插件只能是ActiveX DLL，这个没得选……）

我也一直在用你的DLL编译工具.在做ERP 了![/quote]

[舉杯邀明月]

引用 15 楼 oBingBuGuDu 的回复:

[quote=引用 12 楼 Chen8013 的回复:] 自从前几年我的“标准DLL编译工具”出来之后，我再也没有使用VB6来编译AcitveX DLL了。 不过还在“酝酿中”的一个VB6插件，以后开发时也只能写成AcitveX DLL的。 （Add-In插件只能是ActiveX DLL，这个没得选……）

我也一直在用你的DLL编译工具.在做ERP 了![/quote]