Минимальный проект MsBuild

[@ReanGD]

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

[@mayorovp]

Если нужно писать на C# — то создание проекта с нуля есть полная глупость. А если проект при построении должен собирать rar-архив с дистрибутивом — то в стандартном процессе сборки оказывается слишком много лишнего.

[@ReanGD]

Вы правда считаете, что сборку дистрибутива проекта следует осуществлять на MSBuild (ну или NAnt и т.п.)?
Я все больше в последнее время склоняюсь к тому, что бы непосредственно компилирование оставить подобным системам, а вот всю обвязку выполнять на python к примеру — это и понятнее и быстрее как мне кажется.

[@mayorovp]

А я что, запрещаю выполнять ее на python?
Когда альтернатив много — это хорошо.

[@HomoLuden]

Cruise Control + WiX
или
Cruise Control + [use]any_scripting_lang_you_prefer[/use]

[@mayorovp]

Ага, а если используется TFS? (Только не спрашивайте, нафига. Сами уже не знаем.)

[@HomoLuden]

Я, может, неполностью понимаю главную задачу, но возможно проще будет через Post Build Events запустить кастомный скрипт (.bat | ruby «some_custom_task.rb» | py «как_то_там_незнаю»)?

[@HomoLuden]

Да и сам TFS, вроде, кастомные таски позволяет делать.

[@mayorovp]

Кастомный скрипт на PostBuildEvent — да, это проще. Но иногда подобного функционала начинает не хватать.

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

[@HomoLuden]

Ну как вариант, запускать через батный код в Post Build Event'е исполняемый файл или скрипт с нормальными возможностями. Мне, как кодеру, этот подход больше нравится, чем «программирование через XML». Я как то продвигал подход с созданием MSI'ников с IronRuby вместо XML-API от WiX. Те же текстовые конфиги, но в скриптах. Зато кодеру скрипты корежить куда привычнее, чем XML.
PS: в принципе можно и Power Shell использовать для скриптования таких задач, но я с ним пока «на Вы».

[@mayorovp]

Повторю еще раз: иногда нужно вынести некоторое действия в отдельный проект, чтобы НЕ выполнять их при каждом билде.

Как эти действия будут реализованы — ваше дело, но этот самый отдельный проект должен быть в формате MsBuild (или VcBuild).

Пусть для цели Build будет указана только одна задача — Exec, я не против :)

[@mejedi]

Еще есть генераторы типа cmake — интересно как у них с минимальностью генерируемого проектного файла.

[@mayorovp]

cmake не умеет генерировать проекты msbuild

[@mejedi]

Не хотите использовать полученные знания, чтобы написать генератор?

[@mayorovp]

У меня нет достаточного опыта работы с генераторами.

[@edeldm]

Вы меня простите, но масло масляное.

Еще забыли дописать: Проект — это файл!

[@mihasic]

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

и самый простой msbuild-файл для меня содержит по сути:
<MSBuild Projects="MySolution.sln" Properties="Configuration=$(Configuration);TargetFrameworkVersion=v3.5;OutputDir=$(OutputPath)" />


[@mayorovp]

Просто вы можете позволить себе билдить все решение, а мы — нет.

[@FireStorm]

Спасибо. Статья до сих пор актуальна. Используем такой проект для просто хранения файлов в решении. В новых студиях нужно только ToolsVersion поменять на нужную версию, например, «14.0» для 2015-й.