Мне просто интересно, думали ли люди, что стоит научиться использовать синтаксис MSBuild для настройки процесса сборки для проекта .net, или это действительно того не стоит, учитывая легкость, с которой можно создать проект с помощью Visual Studio.
Я думаю о ночных сборках и т. Д., Но тогда нельзя ли использовать запланированное событие, которое использует параметр сборки из командной строки, встроенный в VS? Существуют ли лучшие инструменты?
@kronoz
Я бы сказал ДА.
Отличная особенность MSBuild заключается в том, что если вы измените свои файлы csproj, чтобы включить в них пользовательские шаги сборки, эти шаги будут выполняться из VS или из MSBuild. Кроме того, если у вас когда-либо будет сервер сборки, вам не нужно будет устанавливать полную VS, только SDK для сборки ваших проектов.
MSBuild абсолютно заслуживает того, чтобы потратить время на изучение. После начального обучения (которое на самом деле может быть очень крутым) становится довольно легко выполнять наиболее распространенные шаги автоматизации сборки.
Похоже, вы - единственный разработчик, работающий над собственным сайтом. Если это так, то в этом нет необходимости, но вы все равно должны изучить это как часть вашего профессионального опыта.
Автоматическое построение проектов становится все более необходимым по мере увеличения числа разработчиков, работающих над проектом. Двум разработчикам очень легко написать несовместимый код, который сломается при объединении (представьте, что я вызываю функцию foo (int x), а вы меняете подпись на foo (int x, int y): когда мы объедините наши кодовые базы, код сломается.
Эти типы ошибок усложняются и усложняются с увеличением времени между сборками интеграции. Благодаря настройке ночных сборок или даже сборок, которые выполняются при каждой регистрации, эти проблемы значительно уменьшаются. Эта практика в значительной степени является отраслевым стандартом для проектов с несколькими разработчиками.
Итак, отвечу на ваш вопрос: это навык, который будет применяться в разных проектах и компаниях. Вы должны изучить его, чтобы расширить свои знания и навыки как разработчика, а также добавить важную строчку в свое резюме.
MSBuild определенно стоит изучить всем и каждому, кто пишет программное обеспечение .NET. Причина, по которой сервер сборки для приложений .NET больше не требует установки Visual Studio (как упомянул Эндрю Бернс), заключается в том, что MSBuild теперь является частью .NET Framework.
Знание MSBuild даст вам значительную гибкость в выборе технологий, которые вы будете использовать для реализации непрерывной интеграции. Поскольку я потратил время на изучение MSBuild, я смог без особого труда изменить систему CI, которую использовала одна из наших команд, с CruiseControl.NET на TeamCity. Эти серверы CI или что-то вроде FinalBuilder (с которым я не знаком) являются лучшими вариантами для выполнения ночных сборок, чем запланированная задача. Изучение того, как реализовать настраиваемые задачи MSBuild, даст вам еще больше гибкости в реализации настраиваемых сборок. Живко Петев перечислил ряд задач, которые упрощает MSBuild. В случае развертывания и настройки базы данных я написал сценарии, которые делают это в MSBuild, и это значительно упрощает процесс разработки и тестирования.
Если в вашем будущем появится Visual Studio Team System, приложения, созданные с помощью MSBuild, будет намного проще перенести в эту среду, чем приложения, созданные с помощью альтернативных средств.
Доступно множество ресурсов, которые помогут вам начать работу с MSBuild. Я бы начал с внутри Microsoft Build Engine. У одного из соавторов также есть множество материалов в Интернете, в том числе этот сайт и проект на CodePlex.
Что ж, MSBuild встроен, поэтому, если вы делаете что-то простое, да, это рекомендуется.
Но для чего-то вроде ночных сборок я бы посоветовал FinalBuilder.
См. Этот вопрос об инструментах управления сборкой / конфигурацией.
MSBuild невероятно прост в использовании, вы можете использовать VS для управления проектами и файлами решений и просто передать SLN в MSBuild.
В таком сценарии, как ваш, когда у вас еще нет системы сборки, да, MSBuild того стоит. Вы можете не только использовать его для различных задач перед сборкой и после сборки (см. Ответ Джико Петиова), но также можете интегрировать его в среду непрерывной интеграции (например, CruiseControl).
Один из сценариев, когда это может не иметь смысла, - это когда у вас уже есть автоматизированная система сборки с использованием сценариев. Например, я сам не тратил время на MSBuild, потому что я использовал NAnt для этой задачи еще до того, как существовал MSBuild ...
Сборку из командной строки с помощью MSBuild относительно легко освоить. Начните с открытия командной строки Visual Studio и запуска msbuild /?. Просто прочтите справку один раз, а потом решите, хотите ли вы узнать больше.
Написание файлов проекта немного сложнее. Большинству людей не нужно изучать его, потому что вы можете делать большинство вещей в Visual Studio. Тем не менее, он также довольно эффективен для решения некоторых проблем.
Раньше я использовал MSBuild в качестве языка сценариев в сочетании с множеством настраиваемых задач. MSBuild имеет фантастическую поддержку ведения журналов + встроенное управление зависимостями. Однако выучить этот язык непросто. PowerShell - гораздо лучший выбор.
Если вы разрабатываете в .net Workshop, это стоит обучения.
Я интегрировал наш процесс сборки с Jenkins - первоначально Hudson. Как упоминалось выше, у MSbuild крутая кривая обучения, однако, как только вы поймете основы, вы можете приступить к настройке сборки. мое впечатление до сих пор - могло быть наивно, большая часть сценария состоит из
<PropertyGroup>
<PropertyKey>value</PropertyKey>
</PropertyGroup>
<ItemGroup>
<ItemListKey>List values<ItemListKey>
</ItemGroup>
<Task Source="" Target="" />
Besides using for build, I successfully used MSBuild to create a module that manages
configuration files such as web.config and foo.exe.config files.
it is a hybrid module that consists of .net console app, MSBuild script and batch file.
what this module does is that during a project upgrade, it will create a XML transform
template with connection strings, endpoints and appSettings from old configuration
files.
after the project has been upgraded, the module will transform newly deployed
configuration
files without affecting any new entries. if you have dozens of configuration files this
is very effective.
@kronoz Я бы сказал ДА. Отличительной особенностью MSBuild является то, что если вы измените свои файлы csproj, чтобы включить в них настраиваемые шаги сборки, эти шаги будут выполняться из VS или из MSBuild. Кроме того, если у вас когда-либо будет сервер сборки, вам не нужно будет устанавливать полную VS, только SDK для сборки ваших проектов.
==> Это не совсем так. Например, для сборки проекта установки на сервере сборки потребуется установить Visual Studio !!
