Pull to refresh

Comments 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) может статься из-за незнания кастомный конфиг секций и возможности выноса их в отдельные файлы…
С помощью трансформаций мы покрываем задачи добавления сервисов в секцию WCF, регистрацию плагинов в кастомной секции, добавление регистраций в unity-контейнер, включение логгеров в релиз-конфиграции и т.п.
А еще это может делать всё сетап. Если он, конечно, имеется.
Чуть-чуть сумбурно написано, и ощущение что не хватает вступления… но это ощущения, а в целом — огромное спасибо за статью. Сейчас решаю похожие проблемы, и статья дала много ключевых слов для дальнейшего изучения вопроса.
Согласен, что сумбурно, но хотелось запостить побыстрее. Думаю, напиши еще парочку статей на эту тему, где всё будет подробнее.
Наша команда испытывает необходимость в подобном решении, по этому тема очень интересна. Спасибо, за материал. Есть пара вопросов по вашей реализации.

При сборке проектов происходило определение зависимостей. Функция 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.
Only those users with full accounts are able to leave comments. Log in, please.