Лучший способ управлять сгенерированным кодом в автоматизированной сборке?

Question

В моей автоматической сборке NAnt у нас есть шаг, который генерирует много кода из базы данных (используя SubSonic), и код разделяется на папки, которые соответствуют имени схемы в базе данных. Например:

• / генерируется код
  • / ДБО
    • SomeTable.cs
    • OtherTable.cs
  • / а
    • Customer.cs
    • Order.cs

Имена схем предназначены для изоляции сгенерированных классов, которые понадобятся приложению. Например, есть приложение ABC, которое извлекает сгенерированный код из этой центральной папки. Я делаю это на мероприятии перед сборкой, например:

del / F / Q $ (ProjectDir) Сущности \ генерируемые * .cs

copy $ (ProjectDir) .... \ генерируемый код \ abc * .cs $ (ProjectDir) Объекты \ генерируемый * .cs

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

Итак, вот трение, которое я вижу:

1) Каждое новое приложение должно настроить это событие перед сборкой. Это отстой, когда приходится это делать.

2) На нашем сервере сборки мы не генерируем код, поэтому у меня на самом деле есть IF $ (ConfigurationName) == «Debug» перед каждой из этих команд, так что этого не происходит для сборок релиза

3) Иногда команды не выполняются, что не позволяет нашей локальной сборке. Это потерпит неудачу, если: - сгенерированного кода пока нет (просто создаю новый проект, базы данных пока нет) - в каталоге нет существующего кода (первая сборка)

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

Так что я хотел бы услышать предложения о том, как улучшить это, где это немного более долговечно. Может быть, перенести копирование кода в папки приложения в скрипт NAnt? Это кажется отсталым, но я готов выслушать аргументы для этого.

Ладно, отжигайте:)

Answer 1

Как часто меняется ваша схема БД? Разве нельзя было бы сгенерировать связанные с базой данных файлы по требованию (например, при изменении схемы), а затем проверить их в своем хранилище кода?

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

Answer 2

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

Я могу управлять сценарием NAnt ... Мне просто интересно, есть ли у людей совет по поводу использования 1 сценария NAnt или, возможно, одного для каждого проекта, который может выдвигать код в проекты, а не извлекаться.

Это означает, что вы должны зарегистрироваться для генерации кода.

Answer 3

В нашем решении два проекта, полностью построенных из сгенерированного кода. По сути, мы запускаем генератор кода .exe в качестве шага после сборки для другого проекта, и вместе с генерацией кода он автоматизирует активный экземпляр Visual Studio, чтобы убедиться, что сгенерированный проект находится в решении, что он имеет все сгенерированные файлы кода, и что они извлекаются / добавляются в TFS по мере необходимости.

Он очень редко вылетает на этапе автоматизации VS, и мы должны запускать его «вручную», но это обычно только в том случае, если у вас открыто несколько экземпляров VS с открытым> 1 экземпляром решения и он не может вычислить из которых он должен автоматизировать.

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