Я просто задавался вопросом, считали ли люди, что стоит изучить синтаксис MSBuild, чтобы настроить процесс сборки для проекта .net, или действительно ли это не стоит того, что легко можно построить с помощью визуальная студия.
Я думаю о ночных сборках и т.д., но тогда я не могу использовать запланированное событие, которое использует вариант построения командной строки, встроенный в 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, даст вам еще большую гибкость при реализации пользовательских сборок. Jivko Petiov перечисляет ряд задач, которые MSBuild упрощает. В случае развертывания и конфигурации базы данных я написал сценарии, которые делают это в MSBuild, и это упрощает процесс разработки и тестирования.
Если Visual Studio Team System в вашем будущем, приложения, созданные с использованием MSBuild, будут намного легче перемещаться в эту среду, чем те, которые создаются с помощью альтернативных способов.
Имеется много ресурсов, которые помогут вам начать работу с MSBuild. Я бы начал с Внутри Microsoft Build Engine. У одного из соавторов также есть тонна вещей в Интернете, в том числе этот сайт и проект на CodePlex.
Ну, MSBuild встроен, поэтому, если вы делаете что-то простое, то да, это рекомендуется.
Но для чего-то вроде ночной сборки я предлагаю FinalBuilder.
См. этот вопрос об инструментах управления конструкцией/конфигурацией.
MSBuild невероятно прост в использовании, вы можете использовать VS для управления проектами и файлами решений и просто передавать SLN на MSBuild.
В таком сценарии, как ваш, где у вас еще нет системы сборки, тогда да, MSBuild абсолютно того стоит. Вы можете не только использовать его для множества задач предварительной сборки и пост-сборки (см. Ответ Jicko Petiov), но вы также можете легко интегрировать его в среду непрерывной интеграции (например, CruiseControl).
Один сценарий, где это может не стоить, - это когда у вас уже есть автоматизированная/скриптовая система сборки. Например, я сам не нашел времени с MSBuild, потому что я использовал NAnt для этой задачи, поскольку до того, как существовал MSBuild...
Построение из командной строки с помощью MSBuild относительно легко изучается. Начните с открытия командной строки Visual Studio и запустите msbuild /?. Просто прочитайте справку один раз, а затем решите позже, если хотите узнать больше деталей.
Написание файлов проекта немного сложнее. Большинству людей не нужно это изучать, потому что вы можете делать большинство вещей в Visual Studio. Однако он также достаточно эффективен для определенных проблем.
В прошлом я использовал MSBuild как язык сценариев, в сочетании с множеством пользовательских задач. MSBuild имеет отличную поддержку ведения журнала + встроенное управление зависимостями. Однако это нелегкий язык для изучения. PowerShell - намного лучший выбор.
@kronoz Я бы сказал ДА. То есть вещь о MSBuild заключается в том, что если вы измените свои файлы csproj, чтобы включить пользовательские шаги сборки, затем эти шаги произойдет изнутри ВС или из MSBuild. Также, если у вас есть сборка сервер вам не нужно будет устанавливать полный VS, только SDK для создания вашего проектов.
== > Это не совсем так. Например, для создания проекта установки на сервере сборки потребуется установка Visual Studio!
Если вы работаете в семинаре .net, он учится стоит.
Я объединил наш процесс сборки с Jenkins - изначально Hudson.
Как упоминалось выше, MSbuild имеет крутую кривую обучения. Однако однажды
вы понимаете основные принципы, вы можете начать настройку сборки.
мое впечатление до сих пор - может быть наивным, основная часть script состоит из
<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.