Для моего контроля версий я разрабатываю модули в своем собственном проекте. Он содержит код модуля, тестовый код, код поставщика данных (если применимо) и все остальное. Это проверено в управлении исходным кодом, как и любой другой проект. Обратите внимание, что проект модуля не содержит ссылок на определенный веб-сайт DNN, и в проекте создаются ссылки на DNN на общий каталог bin, который ссылается на целевую сборку. Например, в папке моих проектов у меня есть \ bin460, \ bin480, \ bin510, \ bin520 и т. Д. Каждая из этих папок содержит набор двоичных файлов для определенной версии DNN. Таким образом, вы можете построить против определенной версии, но протестировать против любой версии, которая вам нравится.
Проблема с управлением исходным кодом модуля на месте в установке DNN заключается в
- иногда не весь код модуля легко изолируется в одном родительском каталоге
- не подходит для подхода с модулем PA
- нелегко перенести проект на другую версию DNN для разработки или тестирования
- легкое непреднамеренное управление источниками компонентов решения DNN, особенно с помощью интегрированных решений управления источниками VS.
Этот подход компилируется быстро, потому что вы не пытаетесь скомпилировать весь проект. Для тестового развертывания у меня есть скрипт сборки, который копирует различные части модуля на целевой веб-сайт. Это можно сделать с помощью компиляции (связать скрипт сборки) или просто запустить после успешной компиляции в окне cmd. Мой скрипт сборки имеет целевой переключатель среды, так что я могу сказать «dnn520», чтобы развернуть сборку для моей тестовой установки dnn520. Обратите внимание, что вам нужно сначала вручную создать конфигурацию модуля, прежде чем это сработает, но это одноразовое усилие, и вы можете использовать функцию экспорта для создания манифеста модуля .dnn.
Чтобы собрать пакет модуля, потратьте время на всесторонний скрипт, который возьмет различные части из вашего исходного каталога и поместит их в установочный пакет. Сохраните все части в папке управления исходным кодом и скопируйте их во временный каталог, затем запустите утилиту командной строки zip (я использую древнюю версию pkzip), чтобы упаковать ее в устанавливаемый файл.
Преимущества такого подхода:
- отделение кода модуля от установленного кода
- простой способ сохранить только код модуля в системе контроля версий (не нужно исключать весь код сайта)
- возможность быстрого тестирования модулей в разных версиях dnn
- пакетный скрипт позволяет быстро и легко построить новую версию модуля для установки, тестирования / развертывания
Недостатки
- не может использовать волшебную зеленую кнопку 'go' в VS (нужно вручную подключить отладчик)
- больше времени на настройку, чем при разработке на месте