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

Question

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

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

Вот файл tasks.json, который я использую, и оба метода вызова команд gulp работают. (Вы упомянули task.json, я предполагаю, что это опечатка, это tasks.json)

{
"version": "2.0.0",
"tasks": [
    {
        "label": "Start server and process files",
        "command": "gulp",
        "args": [
            "sync"
        ],
        "type": "shell",
        "options": {
            "cwd": "${workspaceRoot}"
        }
    },
    {
        "label": "Gulp: Start server only",

        "type": "gulp",
        "task": "serve",
        "problemMatcher": []
    },
    {
        "label": "Gulp: watch",

        "type": "gulp",
        "task": "watch",
        "problemMatcher": []
    }
}

Похоже, вы также хотите:

"group": "build",

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

И:

"presentation": {
  "reveal": "always",
},

вместо синтаксиса showoutput.

См. переход к документации задач 2.0 .

5

vb6

задан kemiller2002 18 December 2008 в 18:00

3 ответа

Другие вопросы по тегам:

vb6

Похожие вопросы:

score 2 · Answer 1

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

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

После начальной сборки для создания binarycomptible конюшни каждый не повреждающаяся сборка была бы сделана при помощи простого командного файла 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 обычно делал задание.

score 1 · Answer 2

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

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

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

Назад в день мы использовали Визуальную Сборку, и также Визуальный Делают, который поддерживал компиляцию файлов решения.

score 1 · Answer 3

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

Большая проблема сборок с VB6 обычно возвращается к проблемам совместимости. Худшие проблемы совместимости случая фиксация идет, чему-то нравится это

Создайте (при этом A будь тем все, на что другие ссылаются),

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

Создайте B та ссылка A

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

Создайте C что ссылки B и A

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

и так далее.

Это вызвано тем, что typelibs использования COM DLL ВКЛЮЧАЮТ для добавления в typelibs проектов, на которые они ссылаются. Вы видите, что Тип Освобождает VB6 COM DLL при помощи инструмента OLE View, который идет с Visual Studio 6.0.

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

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

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

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

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