错误48重建代码后加载dll，MSADO相关

当一个ActiveX DLL试图创建另一个实例时，我得到了令人困惑且似乎不一致的结果

在我们重建整个代码库之前，一切都正常工作，这是自几年前接管代码库以来从未做过的事情。我们以前只是根据需要制作一些作品

问题发生在多个地方，但这里有一个代表性的例子：

Dim objMid As MiddlePiece.clsMyClass
Set objMid = CreateObject("MiddlePiece.clsMyClass")

这在

CreateObject

行中遇到错误（48：加载DLL时出错）。我试着改变代码，得到了以下结果

Dim objMid As MiddlePiece.clsMyClass
Set objMid = New MiddlePiece.clsMyClass

这又给了我错误48

Dim objMid As Object
Set objMid = New MiddlePiece.clsMyClass

这也给出了错误48

Dim objMid As Object
Set objMid = CreateObject("MiddlePiece.clsMyClass")

这个确实有效

有人能解释一下这两者之间的真正区别吗？为什么现在只有最后一个有效，而至少第一个有效

我想我理解早期绑定和后期绑定之间的区别，并且只有最后一个示例是后期绑定的实例，但是我已经检查并确认，在构建PC和测试机器上，注册表都包含相同版本的MiddlePiece.dll，所以我不清楚为什么会失败

---

问题似乎源于MiddlePiece.dll是使用Microsoft ActiveX数据对象构建的。自从我们从Windows XP迁移到Windows 7以来，已经有许多与此相关的问题。msado26.tlb库不再适用于我们，因此我们必须将对该库的引用改为引用msado60_Backcompat.tlb。这似乎可以工作一段时间，但是我们在使用两个不同版本的msado15.dll时遇到了更多的问题。最新版本是在VB6和C++中破坏代码。< /P> < P>我们引用了MSADo60BACCOMPAT.TLB的所有引用，引用了MSADo22.TLB，基本上取消了我们两年前过渡到Windows 7时首先实现的“修复”。这基本上都是由于微软引入的问题。对于那些想知道这一点的人来说，这是研究这个问题的一个很好的起点，它允许我们在Windows 7计算机上重建所有内容并解决多个问题。

您是否删除了旧的DLL？如果删除DLL然后编译，它将构成一个新的GUID。如果DLL已经存在，则从现有文件读取guid。您给出的最后一个示例在注册表中查找GUID，因此我们使用二进制兼容性来维护ID。我们已经找到了这个问题。我会补充更多细节。