Комментарии 11
Почему использовался SlowCheetah, а не стандартное средство трансформации конфигов?
Например какое, для ASP.Net? Я больше не знаю. Или писать xslt-преобразование? Так это нужно въезжать во всю эту кухню, ведь не все используют их в повседневной жизни. А в данном случае это удобный гибкий инструмент с простым синтаксисом и быстрым внедрением в реальный проект.
Не знал, что он только для веб-проектов.
Не только. Хотя таржеты действительно из веба, использовать их можно где угодно:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="BeforeBuild">
<TransformXml Source="hibernate.config" Transform="hibernate.$(ActiveConfig).config" Destination="$(TargetDir)\Config\hibernate.config" />
</Target>
* This source code was highlighted with Source Code Highlighter.
1) номер ревизии в VCS я не рекомендую использовать ибо после 2^16 у вас начнутся проблемы.
2) Каждому плагину требовалось модифицировать конфигурацию системы, добавляя или изменяя элементы в файл конфига. А это (если речь идет про app.config) может статься из-за незнания кастомный конфиг секций и возможности выноса их в отдельные файлы…
2) Каждому плагину требовалось модифицировать конфигурацию системы, добавляя или изменяя элементы в файл конфига. А это (если речь идет про app.config) может статься из-за незнания кастомный конфиг секций и возможности выноса их в отдельные файлы…
Чуть-чуть сумбурно написано, и ощущение что не хватает вступления… но это ощущения, а в целом — огромное спасибо за статью. Сейчас решаю похожие проблемы, и статья дала много ключевых слов для дальнейшего изучения вопроса.
Наша команда испытывает необходимость в подобном решении, по этому тема очень интересна. Спасибо, за материал. Есть пара вопросов по вашей реализации.
При сборке проектов происходило определение зависимостей. Функция NuGet-а Enable-PackageRestore (с версии 1.6 включена в расширение для Visual Studio) позволяет выполнять автоматический поиск и скачивание nuget-пакетов нужных версий в процессе компиляции. Нет необходимости храненить бинарные файлы используемых библиотек в VCS. При выполнении сборки проекта на билд-сервере выполнялся аналогичный сценарий. Достаточно в репозитории проекта хранить саму утилиту NuGet с набором target-ов для MSBuild-а.
Вы референсите общий компонент с указанием необходимой версии или нет? Если взять такой пример. Есть компонент Company.Core, который вам надо «разделить» между продуктами A и B. Вы вносите изменение в Company.Core, и собираете проекты A и B. Оба продукта получат обновленную Company.Core? Если так, то в ситуации когда Company.Core был модифицирован для нужд продукта A, то продукт B нуждается в регресионном тестировании. Не сталкивались с такой ситуацией?
Также очень инетересен процес дебага. Реально в локальном окружении использовать Debug версию Company.Core, а при сборке Release.
Не пробовали шарить JavaScript code между несколькими проектами? Если да, то там есть какие-то подводные камни? Можно сделать auto resolve на момент билда?
При сборке проектов происходило определение зависимостей. Функция NuGet-а Enable-PackageRestore (с версии 1.6 включена в расширение для Visual Studio) позволяет выполнять автоматический поиск и скачивание nuget-пакетов нужных версий в процессе компиляции. Нет необходимости храненить бинарные файлы используемых библиотек в VCS. При выполнении сборки проекта на билд-сервере выполнялся аналогичный сценарий. Достаточно в репозитории проекта хранить саму утилиту NuGet с набором target-ов для MSBuild-а.
Вы референсите общий компонент с указанием необходимой версии или нет? Если взять такой пример. Есть компонент Company.Core, который вам надо «разделить» между продуктами A и B. Вы вносите изменение в Company.Core, и собираете проекты A и B. Оба продукта получат обновленную Company.Core? Если так, то в ситуации когда Company.Core был модифицирован для нужд продукта A, то продукт B нуждается в регресионном тестировании. Не сталкивались с такой ситуацией?
Также очень инетересен процес дебага. Реально в локальном окружении использовать Debug версию Company.Core, а при сборке Release.
Не пробовали шарить JavaScript code между несколькими проектами? Если да, то там есть какие-то подводные камни? Можно сделать auto resolve на момент билда?
Можно обновлять версии пакетов в плагинах по необходимости, не сразу как опубликуется новая версия, чтобы отложить тестирование до более подходящего времени. Более усложненные сценарии мы не применяли.
Для дебага скомпилировнные в debug-конфигурации сборки ядра размещаются в output-директории плагина. В свойствах проекта плагина (это class library) при отладке указывается исполняемый сторонний файл. Далее можно запускать выполнение, ставить точки останова и т.п. Для тестирования интерфейса, например, можно подключать фейковые сервисы, используя конфигурацию ioc-контейнера и директивы компиляции.
С js не проделывал такое, но можете посмотреть документацию nuget, там есть примеры с css.
Для дебага скомпилировнные в debug-конфигурации сборки ядра размещаются в output-директории плагина. В свойствах проекта плагина (это class library) при отладке указывается исполняемый сторонний файл. Далее можно запускать выполнение, ставить точки останова и т.п. Для тестирования интерфейса, например, можно подключать фейковые сервисы, используя конфигурацию ioc-контейнера и директивы компиляции.
С js не проделывал такое, но можете посмотреть документацию nuget, там есть примеры с css.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация сборки на .Net с использованием NuGet