![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Тут задают вопрос "откуда ад заборов и коровников"
А давайте я вам расскажу, откуда берутся ебанутые требования к разработчикам и вообще черви и жабы в ИТ. На примере одного простейшего use-case.
Есть, значит, проект на дотнете. Как положено, его исходники лежат под контролем версий (меркуриал). И я, всего лишь, желаю следующего:
1) Проект собирается на машине, где стоит только вижуал студия (а в идеале - только .NET фреймворк)
2) При сборке получающиеся либы имеют версию вида major.minor.номер-релиза.vcsrevision. Т.е. проставить версии исходя из номера ревизии в меркуриале.
Вполне себе нормальное желание - пришел к клиенту, глянул на свойства файла и видишь что за версия, итд.
Так вот, реализация этого дела с уверенностью заводит в один из следующих тупиков:
1) cmd-файлы, вызывающие комманд-лайн меркуриал и генерирующие файлы AssemblyInfo.cs. При дальнейшем развитии получается фреймворк для билда из cmd-файлов, безальтернативно. Ад кромешнейший.
2) вижуал студия с доставленными 100500 расширениями выполняющими именно это, но каждое из которых не умеет чего-нибудь.
3) NAnt с 100500 вручную написанными скриптами сборки, которые нужно синхронизировать с csproj
4) NAnt, который вызывает MSBuild для сборки, т.к. csproj - это на самом деле скрипты MSBuild
5) то, что я пытался сейчас сделать: только MSBuild. Из соображений "не разводить зоопарк". Ага, да.
Значит последовательность действий с MSBuild:
1) Ищем интеграцию MSBuild с меркуриалом, в гугле. Находим: http://msbuildhg.codeplex.com/
2) Качаем. MSBuild.Mercurial-1.1.2.msi. Хер знает что и куда это ставит, поэтому ставим в виртуальной машине. Смотрим, что реально это два файлика MSBuild.Mercurial.dll, MSBuild.Mercurial.tasks и примеры с документацией.
3) Начинаем разбираться в примере, как установить версию. 125 строк, 4 кб xml-файл HgVersion.targets.
4) Файл зависит от MSBuild Community Tasks. Оттуда используется _ОДНО_ описание таска - AssemblyInfo, которое используется для генерации файла AssemblyInfo
5) Ищем MSBuild Community Tasks в гугле: http://msbuildtasks.tigris.org/. Оказывается, проект переехал на гитхаб: https://github.com/loresoft/msbuildtasks
6) Идем туда. Оказывается, чтобы поставить - нужен Package Manager Console. Являющийся частью NuGet. Скачать просто dll и tasks - нельзя.
7) Думаю - попытаюсь собрать самостоятельно. Качаю исходники, распаковываю, запускаю:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe Master.proj
Хрен там. Для сборки ТОЖЕ нужен NuGet: loresoft-msbuildtasks-37dae23\Source\.nuget\nuget.targets(51,9): error : Unable to locate ', ".nuget"))\nuget.exe'
На этом я заябываюсь и иду писать пост в ЖЖ. При этом самодельная реализация того же на бат-файлах - 3 строки бат файла и 10 строк утилитка на дотнете(которую можно заменить awk из GNUWin32, по идее).
Короче, я не знаю, какие сделать из этого выводы. Наверно, проще в корне сборочных скриптов положить файл readme.txt и написать, в какой последовательности что исправлять и что должно стоять на машине, чтобы собрать проекты, потому что попытка сделать "как положено" (системы сборки, общепринятые инструменты) уводит в дебри с первого же шага.
Есть, значит, проект на дотнете. Как положено, его исходники лежат под контролем версий (меркуриал). И я, всего лишь, желаю следующего:
1) Проект собирается на машине, где стоит только вижуал студия (а в идеале - только .NET фреймворк)
2) При сборке получающиеся либы имеют версию вида major.minor.номер-релиза.vcsrevision. Т.е. проставить версии исходя из номера ревизии в меркуриале.
Вполне себе нормальное желание - пришел к клиенту, глянул на свойства файла и видишь что за версия, итд.
Так вот, реализация этого дела с уверенностью заводит в один из следующих тупиков:
1) cmd-файлы, вызывающие комманд-лайн меркуриал и генерирующие файлы AssemblyInfo.cs. При дальнейшем развитии получается фреймворк для билда из cmd-файлов, безальтернативно. Ад кромешнейший.
2) вижуал студия с доставленными 100500 расширениями выполняющими именно это, но каждое из которых не умеет чего-нибудь.
3) NAnt с 100500 вручную написанными скриптами сборки, которые нужно синхронизировать с csproj
4) NAnt, который вызывает MSBuild для сборки, т.к. csproj - это на самом деле скрипты MSBuild
5) то, что я пытался сейчас сделать: только MSBuild. Из соображений "не разводить зоопарк". Ага, да.
Значит последовательность действий с MSBuild:
1) Ищем интеграцию MSBuild с меркуриалом, в гугле. Находим: http://msbuildhg.codeplex.com/
2) Качаем. MSBuild.Mercurial-1.1.2.msi. Хер знает что и куда это ставит, поэтому ставим в виртуальной машине. Смотрим, что реально это два файлика MSBuild.Mercurial.dll, MSBuild.Mercurial.tasks и примеры с документацией.
3) Начинаем разбираться в примере, как установить версию. 125 строк, 4 кб xml-файл HgVersion.targets.
4) Файл зависит от MSBuild Community Tasks. Оттуда используется _ОДНО_ описание таска - AssemblyInfo, которое используется для генерации файла AssemblyInfo
5) Ищем MSBuild Community Tasks в гугле: http://msbuildtasks.tigris.org/. Оказывается, проект переехал на гитхаб: https://github.com/loresoft/msbuildtasks
6) Идем туда. Оказывается, чтобы поставить - нужен Package Manager Console. Являющийся частью NuGet. Скачать просто dll и tasks - нельзя.
7) Думаю - попытаюсь собрать самостоятельно. Качаю исходники, распаковываю, запускаю:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe Master.proj
Хрен там. Для сборки ТОЖЕ нужен NuGet: loresoft-msbuildtasks-37dae23\Source\.nuget\nuget.targets(51,9): error : Unable to locate ', ".nuget"))\nuget.exe'
На этом я заябываюсь и иду писать пост в ЖЖ. При этом самодельная реализация того же на бат-файлах - 3 строки бат файла и 10 строк утилитка на дотнете(которую можно заменить awk из GNUWin32, по идее).
Короче, я не знаю, какие сделать из этого выводы. Наверно, проще в корне сборочных скриптов положить файл readme.txt и написать, в какой последовательности что исправлять и что должно стоять на машине, чтобы собрать проекты, потому что попытка сделать "как положено" (системы сборки, общепринятые инструменты) уводит в дебри с первого же шага.
no subject
no subject
no subject
Я тоже как-то занимался MSBuild-ом и CCNet-ом. В принципе оно все так и делается, главный паттерн - все что нужно сваливать прям в VSC (включая бинарники утилит, все нужные сборки, конфиги CCNet-ов и т.п.). Вроде жить можно.
no subject
no subject
powershell script? :)