Когда вы ссылаетесь на ActiveX или COM DLL-файлы и EXE-файлы, вы практически не контролируете, какой DLL-файл или EXE-файл фактически используется, потому что VB6 работает строго из GUID и реестра Windows. Ключ к работе с VB6 и ActiveX, а также к сохранению здравомыслия - это понимание двоичной совместимости. (См. http://www.vbsight.com/BinaryComp.htm).
Вот мой совет относительно проектов ActiveX / COM (будь то EXE, DLL или OCX):
(1) Подробнее о настройках двоичной совместимости.
(2) Хорошей практикой является добавление суффикса к эталонному исполняемому файлу с расширением .cmp, например Project1.dll.cmp. Когда вы посмотрите на двоичную совместимость, вы поймете, что я имею в виду.
(3) Разрабатывайте проекты VB6 ActiveX внутри VirtualPC; Разработка VB6 ActiveX сильно изнашивает реестр Windows.
(4) Путь к файлу к DLL / EXE / OCX в настройке Reference = изменится, когда у VB будет причина для обнаружения объекта ActiveX; это пойдет с тем, что он найдет в реестре (выигрывает последний, зарегистрировавшийся). Также есть «Обновить элементы управления ActiveX», устанавливающие свойства проекта, которые могут вносить изменения.
(5) У вас практически нет контроля над GUID или библиотекой типов, которые генерирует VB6, за исключением той степени, которую вы можете достичь с помощью надлежащего управления двоичной совместимостью.