Тут задают вопрос "откуда ад заборов и коровников"

[metaclass]

А давайте я вам расскажу, откуда берутся ебанутые требования к разработчикам и вообще черви и жабы в ИТ. На примере одного простейшего 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 и написать, в какой последовательности что исправлять и что должно стоять на машине, чтобы собрать проекты, потому что попытка сделать "как положено" (системы сборки, общепринятые инструменты) уводит в дебри с первого же шага.

Comments

[metaclass.livejournal.com]

В каком плане?
Обычная задача (версионирование из VCS), обычные граничные условия (чистая сборка, минимум зависимостей, минимизация использования различных скриптовых языков).
Результат: с большой вероятностью ебаный ад. С причинами пока не разобрался.

[eternal-leave.livejournal.com]

Вот результат и запущен :)

[craneop.livejournal.com]

После этого пишут что в жабе ад. Ну ну.

[metaclass.livejournal.com]

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

[jakobz.livejournal.com]

Написать утилитку на дотнетах, скомпилировать, положить в VCS, запускать как post-build task.

[metaclass.livejournal.com]

Именно так, видимо и надо сделать, только pre-build task

[jakobz.livejournal.com]

Ага. А ревизию и тупо запустив hg можно вытащить.

Я тоже как-то занимался MSBuild-ом и CCNet-ом. В принципе оно все так и делается, главный паттерн - все что нужно сваливать прям в VSC (включая бинарники утилит, все нужные сборки, конфиги CCNet-ов и т.п.). Вроде жить можно.

[antilamer.livejournal.com]

Мы, кажется, так и делали.

[smalgin.livejournal.com]

just for lulz

powershell script? :)

[jakobz.livejournal.com]

Запуск студии вместо msbuild:
- не даст никакой разницы в том что происходит (т.к. msbuild понимает .sln, а csproj - это родной ее формат)
- может быть в разы медленнее (т.к. надо загружать эту слонятину)

[jakobz.livejournal.com]

Вообще решительно неясно почему рядом к csc в .net не положили runcs.exe с понятным назначением. Можно еще оборачивать все эти using/namespace/class/main чтобы букв писать поменьше.

Был бы на 90% тачек нормальный язык для всякого скриптования. На C#, как по мне, всякие "считай-запиши текст/xml" делаются весьма неплохо. Плюс, в отличии от awk и прочих bat-файлов оно нормально потом усложняется при необходимости.

[metaclass.livejournal.com]

Да, C# вполне приемлемо для таких целей.
Там в принципе, иерархии задач типа как в make, не особо опишешь, но мелкие императивные задачи вполне нормально решать.

[n16bs.livejournal.com]

Есть же PowerShell в котором в каком-то виде можно юзать дотнет. Правда подозреваю, что реализовано это ужасно, но он есть.

[jakobz.livejournal.com]

PowerShell - это еще один язык, причем весьма извращенный. Если еще бы его ставить не надо было отдельно - можно было бы и попробовать. А так - не вижу смысла.

[n16bs.livejournal.com]

А как насчёт написать свой таск для MSBuild'a который сделает всё что нужно?

[metaclass.livejournal.com]

Можно попробовать. Опасаюсь, что в итоге я окажусь где-нибудь в дебрях апи msbuild где ад заборы и коровники)

[n16bs.livejournal.com]

Ну мы задачу "скормить cli тулзе сборки после билда" решили так. Там всё просто:

public class MyTask : Task
{
[Required] public string Param1 { get; set; } // параметр из билдскрипта

public override bool Execute()
{
// кормим жаб
}
}

[metaclass.livejournal.com]

Все, так и сделал. Таск запускает меркуриал и генерирует нужные файлы исходя из его показаний.
MSBuild ведет себя как положено, деплоймент результата его же средствами, пока все ок.

[metaclass.livejournal.com]

Чорт, удалил полезный комент от анонимуса
"Любовь некоторых людей к кактусам иногда поражает всякое воображение. Ведь стоит один раз признать очевидную вещь, - сиришотка не язык, а венда не операционка, - и всё становится просто, ясно и красиво, но нет, мыши будут плакать и колоться."

Так вот, что я хотел сказать: оно так и есть, но блин, клиенты хотят винду и C#.

[jakobz.livejournal.com]

C# - нормальный язык. Я вообще думаю что он, с прагматической точки зрения - один из лучших на данный момент. Ява вообще сосет вприсядку. Динамические языки динамические. А остальное все может и хорошо, но весьма маргинально.

В .net другое посасывает, с языком все ок.

[victor bolshakov (from livejournal.com)]

.NET хорош тем, что изначально к языку не привязан.

[si14.livejournal.com]

Разрешите поинтересоваться — что не так с динамическими языками? Не говнопитоном, а чем-нибудь более нормальным вроде кложури или эрланга.

[jakobz.livejournal.com]

С прагматической точки зрения: нельзя приделать корректный автокомплит. Ну т.е. приходит человек с института, нажимает ctrl+space, и он все уже знает и все умеет.

С романтической точки зрения, наука говорит что динамические языки - от бедности.

[(Anonymous)]

> клиенты хотят винду и C#.
Сочувствую.

[victor bolshakov (from livejournal.com)]

клиенты платят деньги.

[alexandr0.livejournal.com]

Клиенты, которые не хотят винду и дотнет, по-вашему, не платят?

[blueher.livejournal.com]

> Так вот, реализация этого дела с уверенностью заводит в один из следующих тупиков:
1) cmd-файлы, вызывающие комманд-лайн меркуриал и генерирующие файлы AssemblyInfo.cs. При дальнейшем развитии получается фреймворк для билда из cmd-файлов, безальтернативно. Ад кромешнейший.
2) вижуал студия с доставленными 100500 расширениями выполняющими именно это, но каждое из которых не умеет чего-нибудь.
3) NAnt с 100500 вручную написанными скриптами сборки, которые нужно синхронизировать с csproj
4) NAnt, который вызывает MSBuild для сборки, т.к. csproj - это на самом деле скрипты MSBuild
5) то, что я пытался сейчас сделать: только MSBuild. Из соображений "не разводить зоопарк". Ага, да.

я в таких случаях давно и безнадёжно агитирую за JavaScript в ипостаси WSH. Есть на всех виндах включая забытые Богом 95-е, умеет дёргать почти все COM-компоненты, запускать exe-ники и прочая, прочая. При этом - читается куда легче чем все эти CMD. Ну и из всех билд-систем отлично запускается как внешний процесс (если в билд надо вклиниться посредине). При небольшой сноровке весьма удобно. А если захотеть странного - так на нём можно ещё и UI писать, в виде MS HTA. Короче, эдакий некросплатформенный питон.

[blueher.livejournal.com]

Забыл добавить важную вещь - в отличие от CMD эту штуку можно отлаживать. Не слишком интересный фичер для мелких скриптов, но мы ж знаем как быстро растут чужие дети маленькие скрипты...

[jakobz.livejournal.com]

Херасе. Пару вопросиков можно?
- насколько совместим с браузерным яваскриптом?
- как дергать, какой командой?

[shredder-by.livejournal.com]

wscript блаблабла.js

[blueher.livejournal.com]

> - насколько совместим с браузерным яваскриптом?
Вплоть до IE9 (а может и в нём тоже, просто они там чего-то наменяли а у меня ещё не дошли руки смотреть) реализация собственно языка JavaScript одна и та же что в IE что в WSH (используется одна и та же jscript.dll). Но естессно что DOM-овских обьектов (document и т.п.) в нём нет, зато есть глобальный обьект WScript который и позволяет дёргать всё что угодно в системе.

> - как дергать, какой командой?
cscript.exe <имяфайла>

[alant.livejournal.com]

У нас этим занимается другое червие - TeamCity. В нём придумали спец таск, шоп патчить AssemblyInfo.cs. Как оказалось, решение не без проблем, т.к. в WCF до .NET 4.0 надо указывать strong name и звёздочки в версии сборки не прокатывают

[alant.livejournal.com]

Уточнение

> в WCF до .NET 4.0 надо указывать strong name
это касалось extensions и custom behavior, которые лежали в отдельной длл

[pascendi.livejournal.com]

Мыши плакали, кололись, но продолжали е..ть кактус.

Майкрософт такой майкрософт...

[victor bolshakov (from livejournal.com)]

Дело не в микрософте. Просто хочется максимально вылизать билдпроцесс.

[darkdrip.livejournal.com]

эта, CS-Script совсем не подходит?

[victor bolshakov (from livejournal.com)]

Руками писать дилдскрипт для большого проекта это удавицца просто.

[metaclass.livejournal.com]

И таки да, это самый настоящий ДилдСкрипт.

[guamoka.livejournal.com]

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

[metaclass.livejournal.com]

Да.
Впрочем, я их победил таки - исключил наиболее дебильные варианты (cmd-файлы, ручные утилиты) - оставил msbuild и кастомное расширение к нему тут же в репозитории. Все работает, как перфекционизм предписывает.

[bydl0coder.livejournal.com]

Пост-коммит хук?

[metaclass.livejournal.com]

Под виндами не работоспособны)

[black-angel-by.livejournal.com]

Ребе, напишите уже ебилд на свой проект :)

[si14.livejournal.com]

Да уж. Как же я доволен после этого экосистемой эрланга: git pull && rebar get-deps compile && ./start-dev.sh