Что может вызвать ошибку времени выполнения Vb6 430

Question

У меня есть COM dll, написанный на vb6. Когда я пытаюсь создать новый объект модуля класса из этой dll, я получаю ошибку таймера выполнения 430: класс не поддерживает автоматизацию или не поддерживает ожидаемый интерфейс. Интересно то, что это происходит только из-за пределов IDE, когда я отлаживаю из-за пределов IDE, ошибки не выдается, и новый объект класса создается успешно. В чем может быть причина?

В общем, я иногда получаю подобные ошибки в COM-библиотеках. Каков наилучший способ устранения неполадок COM? Как я могу узнать путь к dll, который используется при запуске программы?

Answer 1

Если этот проект полностью в VB6. Вероятной причиной этого является то, что в каталоге EXE находится копия двоичного файла DLL. При запуске он использует эту копию вместо скомпилированной копии. Когда вы добавляете методы или классы, этот EXE становится несовместимым со старой DLL. Если вы исправили ошибку или просто работали с внутренним кодом, тогда EXE запустится, но использовала старую DLL.

Установите для вашей DLL двоичную совместимость. Убедитесь, что у вас есть совместимый каталог. Поместите туда DLL последней версии. Укажите двоичную совместимость с этой DLL. Убедитесь, что ваш EXE-файл компилируется в каталог проекта. Запустите EXE из своего каталога проекта. Таким образом, он будет использовать скомпилированную вами DLL. Вам нужно написать утилиту, чтобы вы могли компилировать каждый проект отдельно. Проверьте настройки с помощью Virtual PC или другого компьютера.

Все эти шаги помогут избежать DLL Hell. В моем собственном проекте два десятка проектов ActiveX в 6 слоях. Когда я принял вышеизложенное, мои проблемы с DLL-адом практически прекратились.

Answer 2

Совместно читайте о бинарном и проектном проектах.

Если у вас есть совместно используемая dll, вы должны быть осторожны и использовать двоичный файл совместимо. Таким образом, VB6 будет сохранять ту же сигнатуру / интерфейс COM между сборками. Вы должны иметь копию выпущенной DLL для VB6 для сравнения - у меня обычно есть отдельная папка для выпущенных двоичных файлов. Ограничение двоичной совместимости состоит в том, что вы не можете удалять публичные свойства или методы и не можете изменять их подписи. Вы можете добавлять новые свойства и методы.

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

Answer 3

Это почти наверняка проблема управления версиями, иногда известная как "ад DLL".

Предпосылкой является то, что мир .NET явно разработан, чтобы позволить интерфейсам развиваться, сохраняя то же имя. Но в мире COM интерфейсы считаются неизменными.

Когда вы работаете в среде IDE, Visual Studio создает новую оболочку COM Interop для COM dll каждый раз, когда вы запускаете свое решение. Но если вы не будете выпускать и заменять все свое решение каждый раз, включая совершенно новую оболочку COM Interop, вы столкнетесь с проблемой управления версиями, когда код .NET ожидает один интерфейс COM, но видит другой.

РЕДАКТИРОВАТЬ : По некоторым причинам я предположил, что вы пытаетесь использовать компонент COM из компонента .NET. Если все решение на самом деле VB6, то решение г-на Конли - рекомендуемый подход. Вот хорошая ссылка , в которой обсуждается проблема.