Почему библиотека типов в моей dll повреждена (регистрация возвращает TYPE_E_CANTLOADLIBRARY)?

Question

У нас есть зрелая кодовая база C ++ COM, которая создавалась, регистрировалась и работала в течение многих лет. Сюда входят многочисленные машины для разработчиков и машины для автоматической сборки.

Кодовая база строит несколько библиотек и исполняемых файлов. Некоторые из них являются COM-серверами.

Типичная настройка - Xp64 с использованием Visual Studio 2005 и 2008.

У нас есть как 32-битные, так и 64-битные сборки.

Внезапно наша машина автоматического построения xp64 2005 выходит из строя. Единственным изменением кода было тривиальное изменение в вспомогательном методе c ++ и обновление некоторых номеров версий.

Ошибка, которую мы видим, это ошибка регистрации версии DLL для 64-разрядной версии.

Ошибка, по-видимому, вызвана поврежденной DLL. DLL успешно строится, но попытка зарегистрировать ее не удалась с помощью TYPE_E_CANTLOADLIBRARY.

Предполагается, что dll имеет встроенную библиотеку типов (через включение в файл rc).

Это всегда работало раньше и работает на других наших машинах, xp64 VS 2005 и 2008.

При проверке двоичного файла сломанной dll можно увидеть источник библиотеки libl типа - хотя он находится в другом месте, чем в не сломанной версии dll.

Сломанная dll не регистрируется на других наших машинах - те же самые машины успешно регистрируют свои собственные локальные сборки той же dll.

Oleview также не работает с той же ошибкой при открытии библиотеки.

Я ищу какие-либо предложения или подобный опыт, который мог бы помочь?

Answer 1

Что ж, я думаю, что мы это исправили как визуальную студийную ошибку.

Мы обнаружили, что путь, по которому запускаются наши автокомпиляции, был недавно изменен, увеличив абсолютную длину пути любых файлов, которые генерирует компилятор.

Мы также знаем, что целевая папка 64-битной версии будет иметь самый длинный путь из всех наших конфигураций.

Мы сократили путь (переименовав наш каталог верхнего уровня, в котором проверяется наше дерево исходных текстов).и проблема, похоже, исчезла - очевидно, мы повторим это несколько раз, чтобы убедиться, что это не случайность.

Я думаю, что когда Visual Studio вставляет абсолютное имя пути в двоичный файл- как это все еще происходит - это может привести к переполнению буфера ... и повреждению двоичного файла.

Answer 2

Это может быть так же просто, как диск на сервере сборки, выходящий из строя. В вашем посте нет ничего, что подсказывало бы что-нибудь более сложное. Хотя довольно странно видеть IDL обратно в DLL, библиотеки типов являются двоичными.