我们有一个成熟的c ++ COM代码库，它已经构建，注册和运行多年。这包括许多开发人员机器和自动机器。
代码库构建了几个dll和exes。其中一些是COM服务器。
典型的设置是使用Visual Studio 2005和2008的Xp64。
我们有32位和64位版本。
突然间，我们的xp64 2005 autobuild机器出现故障。 唯一的代码更改是在c ++帮助程序方法中的一个微不足道的更改和对某些版本号的更新。
我们看到的失败是未能注册dll的x64版本。
失败似乎是由损坏的dll引起的。 dll构建成功但尝试注册它失败了TYPE_E_CANTLOADLIBRARY。
dll应该内置类型库（通过rc文件中的include）。
这在以前一直有效，并且仍可在我们的其他机器上运行，xp64 VS 2005和2008。
当检查破坏的dll的二进制文件时，可以看到类型库idl源 - 尽管它位于与非破坏版本的dll不同的位置。
破坏的dll无法在我们的其他计算机上注册 - 相同的计算机成功注册了他们自己的同一dll的本地版本。
当打开dll时，Oleview也会因同样的错误而失败。
我正在寻找可能有帮助的任何建议或类似经历？
答案 0 :(得分：1)
这可能就像构建服务器上的磁盘坏了一样简单。你的帖子中没有任何内容表明任何更复杂的内容。虽然在DLL中看到IDL非常奇怪，但类型库是二进制的。
答案 1 :(得分：1)
嗯，我认为我们已将此作为视觉工作室的错误。
我们发现我们的autobuild运行的路径最近已被更改 - 增加了编译器生成的任何文件的绝对路径名长度。
我们也知道64位版本构建的目标文件夹将具有我们任何配置的最长路径名。
我们缩短了路径（通过重命名我们检查源树的顶级目录）并且问题看起来已经消失了 - 显然我们会重复这几次以确保它不是侥幸
我在想，当visual studio在二进制文件中插入绝对路径名时 - 就像它仍然一样 - 它可能在缓冲区上超载......并破坏二进制文件。