Как сделать разработку и встроить Visual Basic 6.0

Question

Я ищу лучшую практику в построении нескольких визуальных базовых проектов (все DLL). У нас есть несколько проектов, и наш конечный результат будет DLL. Теперь один проект использует 2 других проекта, а другой относится к другому проекту. Должны ли проекты ссылаться на файлы vbp или dll? Если они ссылаются на файлы VBP, как построить все проекты?

Answer 1

После нескольких лет работы с VB6 наши проекты были структурированы следующим образом:
Весь исходный текст проекта (проект и источник) организован в папке источника.
\ Проект \ источник
\ Проект \ источник \ project1 \
\ Проект \ источник \ project2 \
...
Все двоичные файлы (.dll и .exe) в одной папке bin.
\ Проект \ Bin \

Все .dll, заданные как двоичные файлы, совместимы с результирующим файлом в одной папке bin.

После первоначальной сборки, чтобы сделать двоичный код стабильным, каждая неразрывная сборка будет это можно сделать с помощью простого командного файла build.cmd, расположенного в папке над исходной папкой, например:
"c: \ Program Files \ Microsoft Visual Studio \ VB98 \ VB6.EXE" / M. \ source \ project1 \ proj1.vbp
"c: \ Program Files \ Microsoft Visual Studio \ VB98 \ VB6.EXE" / M. \ source \ project2 \ proj2.vbp
"c: \ Program Files \ Microsoft Visual Studio \ VB98 \ VB6.EXE" / M. \ source \ project3 \ proj3.vbp
del. \ bin \ *. exp
del. \ bin \ *. lib

Порядок сборки должен быть в порядке зависимости.
Всякий раз, когда происходит критическое изменение, зависимый проект VB должен быть привязан к новому двоичному файлу.
Не нарушая изменений, build.cmd обычно делал свою работу.

Answer 2

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

Большая проблема сборок с VB6 обычно связана с проблемами совместимости. В худшем случае проблемы с совместимостью исправление выглядит примерно так

Сборка A (где A - это ссылка на все остальные)

Скопируйте A в каталог совместимости

Сборка B с ссылкой A

Скопируйте B в каталог совместимости

Сборка C, которая ссылается на B и A

Скопируйте C в каталог совместимости.

и т. Д.

Это потому, что библиотеки типов библиотеки COM DLL используют INCLUDE для добавления в библиотеки типов проектов, на которые они ссылаются. Вы можете увидеть Type Libs в VB6 COM DLL с помощью инструмента OLE View, поставляемого с Visual Studio 6.0.

Во многих случаях добавление методов или свойств приводит к сбою DLL, потому что MS Method установки Typelibs делает их не совместимыми в двоичном формате. Это не удается, если в противном случае добавление разрешено правилами двоичной совместимости.

Решение, которое работает в 90% случаев, состоит в том, чтобы всегда помещать новейшую версию библиотек DLL, являющихся ссылками, в каталог совместимости.

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

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

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

Answer 3

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

Вы можете использовать параметры сохранения совместимости, чтобы облегчить эту проблему. Убедитесь, что вы используете хотя бы уровень проекта (если вы делаете COM +, то вам нужен двоичный файл, основанный на уже скомпилированной версии dll)

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

Раньше мы использовали Visual Build , а также Visual Make , который поддерживал компиляцию файлов решения.