Comments 19
А что стало побудительной причиной создавать проект руками с нуля? На мой вкус стандартный сгенерированный проект вполне имеет достаточные возможности к расширению, при этом заведомо корректен с точки зрения VS.
Если нужно писать на C# — то создание проекта с нуля есть полная глупость. А если проект при построении должен собирать rar-архив с дистрибутивом — то в стандартном процессе сборки оказывается слишком много лишнего.
Вы правда считаете, что сборку дистрибутива проекта следует осуществлять на MSBuild (ну или NAnt и т.п.)?
Я все больше в последнее время склоняюсь к тому, что бы непосредственно компилирование оставить подобным системам, а вот всю обвязку выполнять на python к примеру — это и понятнее и быстрее как мне кажется.
Я все больше в последнее время склоняюсь к тому, что бы непосредственно компилирование оставить подобным системам, а вот всю обвязку выполнять на python к примеру — это и понятнее и быстрее как мне кажется.
А я что, запрещаю выполнять ее на python?
Когда альтернатив много — это хорошо.
Когда альтернатив много — это хорошо.
Cruise Control + WiX
или
Cruise Control + [use]any_scripting_lang_you_prefer[/use]
или
Cruise Control + [use]any_scripting_lang_you_prefer[/use]
Ага, а если используется TFS? (Только не спрашивайте, нафига. Сами уже не знаем.)
Я, может, неполностью понимаю главную задачу, но возможно проще будет через Post Build Events запустить кастомный скрипт (.bat | ruby «some_custom_task.rb» | py «как_то_там_незнаю»)?
Да и сам TFS, вроде, кастомные таски позволяет делать.
Кастомный скрипт на PostBuildEvent — да, это проще. Но иногда подобного функционала начинает не хватать.
Кроме того, PostBuildEvent выполняется при каждом билде основного проекта, а иногда хочется, чтобы дополнительный функционал (тот же дистрибутив) билдился только когда его об этом попросят.
Кроме того, PostBuildEvent выполняется при каждом билде основного проекта, а иногда хочется, чтобы дополнительный функционал (тот же дистрибутив) билдился только когда его об этом попросят.
Ну как вариант, запускать через батный код в Post Build Event'е исполняемый файл или скрипт с нормальными возможностями. Мне, как кодеру, этот подход больше нравится, чем «программирование через XML». Я как то продвигал подход с созданием MSI'ников с IronRuby вместо XML-API от WiX. Те же текстовые конфиги, но в скриптах. Зато кодеру скрипты корежить куда привычнее, чем XML.
PS: в принципе можно и Power Shell использовать для скриптования таких задач, но я с ним пока «на Вы».
PS: в принципе можно и Power Shell использовать для скриптования таких задач, но я с ним пока «на Вы».
Повторю еще раз: иногда нужно вынести некоторое действия в отдельный проект, чтобы НЕ выполнять их при каждом билде.
Как эти действия будут реализованы — ваше дело, но этот самый отдельный проект должен быть в формате MsBuild (или VcBuild).
Пусть для цели Build будет указана только одна задача — Exec, я не против :)
Как эти действия будут реализованы — ваше дело, но этот самый отдельный проект должен быть в формате MsBuild (или VcBuild).
Пусть для цели Build будет указана только одна задача — Exec, я не против :)
Еще есть генераторы типа cmake — интересно как у них с минимальностью генерируемого проектного файла.
Вы меня простите, но масло масляное.
Еще забыли дописать: Проект — это файл!
Еще забыли дописать: Проект — это файл!
честно не могу понять смысла делать свой проект, всегда использую msbuild для сборки всего солюшина, иногда для дополнительных задач (копирование ресурсов, запуск юнит-тестов, собирание инсталяционных скриптов в папку артефактов).
и самый простой msbuild-файл для меня содержит по сути:
и самый простой msbuild-файл для меня содержит по сути:
<MSBuild Projects="MySolution.sln" Properties="Configuration=$(Configuration);TargetFrameworkVersion=v3.5;OutputDir=$(OutputPath)" />
Спасибо. Статья до сих пор актуальна. Используем такой проект для просто хранения файлов в решении. В новых студиях нужно только ToolsVersion поменять на нужную версию, например, «14.0» для 2015-й.
Sign up to leave a comment.
Минимальный проект MsBuild