Buildprocess для корпоративных проектов ActiveX / COM / VB6

Question

Мы разработали программную систему с использованием технологии ActiveX / COM (VB6) от Microsoft. В прошлом году меня все больше интересуют автоматизированные процессы сборки и SCM в целом. Я интенсивно искал в больших частях Интернета информацию о лучших методах работы scm с программными системами на основе COM.

«Проблема» с COM заключается в том, что ссылающийся компонент содержит ссылку с уникальным идентификатором интерфейса. Когда вы перекомпилируете указанный компонент, идентификатор может измениться, и ссылка больше не действительна. Основная проблема заключается в том, что iid компилируется в двоичный файл. Поэтому, когда я не хочу возвращать скомпилированные файлы в систему управления версиями, каждый разработчик должен скомпилировать свои собственные версии и получить другие идентификаторы.

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

Мне просто интересно, если есть какие-то лучшие практики, как настроить систему автоматической сборки для проектов COM (VB6)?

Edit: Да, я в курсе настроек совместимости. Но возьмите сценарий, в котором я хочу собрать систему Wohle на чистой машине без каких-либо двоичных файлов. Когда вы говорите, что проект совместим с двоичным файлом, вы должны указать двоичный файл, с которым проект совместим.

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

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

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

Answer 1

Вы можете указать VB6 повторно использовать GUID (LID идентификатора CLSID IID и т. Д.), Изменив настройку совместимости проекта с «Нет совместимости» на «Двоичная совместимость». Вы можете найти эти настройки в Project -> Your-Project Свойства. Параметр совместимости находится на вкладке Компонент окна Свойства проекта. Есть три варианта:

• Нет совместимости
• Совместимость проекта
• Двоичная совместимость

Вот что MSDN говорит о них:

Нет совместимости

С этим параметром нет совместимость обязательна. визуальный Basic создает новые идентификаторы интерфейса и Идентификаторы классов каждый раз, когда вы создаете или скомпилируйте свой проект. Каждая версия встроенный может быть использован только с приложения, созданные для работы с этим специфическая сборка компонента.

Совместимость проекта

С помощью этой настройки вы можете сделать проект совместим с конкретным Компонент проекта. Пока новый тип библиотечная информация генерируется, поддерживается идентификатор библиотеки типов так что тестовые проекты все еще могут ссылаться к компоненту проекта. Эта настройка для поддержания совместимости во время тестирования. Поэтому, как только компонент выпущен, он ведет себя такой же, как параметр «Нет совместимости».

Двоичная совместимость

Когда вы компилируете свой проект, Visual Basic создает только новый класс и Идентификаторы интерфейса при необходимости. Это сохраняет идентификаторы класса и интерфейса из предыдущей версии (версий), так что программы, скомпилированные с использованием ранее версия продолжит работать. если ты вносим изменения, которые приведут к в несовместимой версии, Visual Основные предупредит вас. Если хотите поддерживать совместимость со старшими, выпущенные версии ActiveX компонент, это настройка, которую вы нужно использовать.

Звучит так, как будто вы сейчас компилируете с Нет совместимости . Как говорится в статье MSDN, вам нужно использовать Binary Compatibility , чтобы новые версии ваших компонентов были совместимы со старыми версиями. Вы можете сделать это сейчас, выполнив следующие действия:

• Компилировать каждый проект один раз с Нет совместимости

• Сохраните эти "чистые" версии в папке, к которой люди, выполняющие сборки, могут легко получить доступ, например, в сетевой папке, или поместить их в систему контроля версий.

• Вернитесь назад и измените все проекты на «Двоичная совместимость» и укажите «Совместимый файл» на соответствующую версию, которую вы только что сохранили в сети / в системе контроля версий (не указывайте совместимый файл на тот же путь, по которому вы компилируете проект. Совместимый файл должен быть отдельной копией исходного компонента, который не изменится. Он существует только для того, чтобы VB мог скопировать идентификаторы из этого файла в ваш проект при его перекомпиляции).

Каждый раз, когда вы перекомпилируете свои проекты, они будут повторно использовать GUID из совместимых (оригинальных) версий компонентов.

РЕДАКТИРОВАТЬ: Как Джо упомянул в комментариях, вы также должны распознавать, когда ваши интерфейсы класса изменились (то есть, когда интерфейс изменяется достаточно, чтобы вы могли дольше поддерживать двоичную совместимость с предыдущими версиями). Когда это происходит, вы хотите сделать чистый отрыв от предыдущих версий компонентов: перекомпилировать новую «чистую» версию (т.е. без совместимости) и использовать эту новую версию в качестве совместимого файла в будущих сборках. Тем не менее, важно отметить, что начинать заново следует только при изменении интерфейсов классов (свойств и методов). Фактически, VB предупредит вас, когда проект больше не будет совместим с предыдущей версией компонента.

Если хочешь жить на грани ...

Там, где я работаю, мы склонны (ab) использовать No Compatibility в большинстве наших проектов, даже если это не совсем правильный способ работы (вы должны использовать двоичную совместимость). В нашей компании это приобрело лень, потому что у нас есть автоматизированный инструмент сборки, который собирает все наши проекты для нас, и одна из основных функций этого инструмента заключается в том, что он может автоматически восстанавливать поврежденные ссылки на проекты между проектами. Поскольку инструмент сборки исправляет это для нас, стимул использовать двоичную совместимость меньше.

Почему двоичная совместимость лучше (или ... почему вы не должны делать то, что мы делаем)

Несколько причин, почему двоичная совместимость обычно является лучшим выбором:

• Microsoft так говорит

• Если все ваши компоненты двоично совместимы с предыдущими выпусками вашего программного обеспечения, вы можете легко перекомпилировать один компонент и распространить его среди своих клиентов. Это облегчает развертывание исправлений / исправлений. Если вы используете No Compatibility в своих проектах, вам придется перекомпилировать и перераспределять все приложение каждый раз, когда требуется небольшой патч, потому что более новые компоненты (вероятно) не будут работать со старыми компонентами.

• Вы вносите свой вклад в поддержку стандарта COM: В COM идентификаторы классов и интерфейсов должны однозначно идентифицировать класс или интерфейс. Если ваши классы и / или интерфейсы не менялись между сборками, то нет необходимости генерировать новые идентификаторы для этих классов и интерфейсов (фактически, один и тот же класс будет иметь несколько идентификаторов). Двоичная совместимость позволяет вам поддерживать одинаковые идентификаторы во всех сборках, что означает, что вы являетесь хорошим гражданином и соблюдаете соглашения COM.

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

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

Answer 2

Visual Build Pro . Если вы все еще застряли на земле VB6 и должны создавать профессиональные продукты, я настоятельно рекомендую вам ознакомиться с этим продуктом. Он имеет бесплатную пробную версию и стоит каждой копейки (плюс он делает довольно хорошую работу по непрерывной интеграции для .Net и других платформ.) Он спасал нас от ада DLL на каждом выпуске, так как мы начали использовать его. Я не знаю другого способа создать приличную сборку в VB6.

Answer 3

Как предполагает Майк Спросс, вы должны использовать двоичную совместимость. Вы можете (и должны) строить на чистой машине. Это можно сделать, сохранив копию текущих производственных двоичных файлов (DLL-библиотеки ActiveX и OCX) в «совместимом» каталоге в системе управления версиями. Все проекты должны ссылаться на эту копию при выборе Binary Comatibility. Например, поместите новые двоичные файлы в ... \ Release, а совместимые двоичные файлы живут в ... \ Compatible. Когда новая версия поступает в производство, вы копируете все из ... \ Release в ... \ Compatible. Таким образом вы сохраняете совместимость при переходе от одного выпуска к другому.

В режиме Binary Compatibility VB создаст новый IID, если вы добавите новый метод в ваш класс. Помните, что в COM интерфейс является неизменным. Если вы вносите малейшие изменения в интерфейс, вы создаете что-то новое. VB соблюдает это правило COM, но использует дым и зеркала для предотвращения взлома старого клиентского кода. Поскольку VB «знает», что новый интерфейс является 100% надмножеством старого интерфейса (это то, что обеспечивает двоичная совместимость), он может использовать «переадресацию интерфейса». Переадресация интерфейса просто перенаправляет все ссылки со старого интерфейса на новый интерфейс. Без этого трюка вам пришлось бы создавать новые версии (с разными именами и CLSID) любого компонента ActiveX, который вы изменяете. DLL Ад превратилась бы в DLL Армаргеддон!

VB хранит всю информацию о переадресации интерфейса в ресурсах вашего компонента. Когда вы регистрируете компонент, он записывает все идентификаторы интерфейса в HKCR \ Interface. Старые интерфейсы будут содержать информацию о пересылке. Только «настоящий» интерфейс будет ссылаться на фактический кокласс.