Я должен переключиться от nant до msbuild?
Это потому, что вкладка - это именование контейнера, а ваше обновление должно быть update="Search:insTable:display". Что вы можете сделать, просто разместите свое диалоговое окно вне формы и все еще внутри вкладки, тогда оно будет: update="Search:display"
17 ответов
Мне нравится MSBuild. Одна причина состоит в том, что .csproj файлы являются msbuild файлами, и создающий в VS точно так же, как создает в командной строке. Другой причиной является хорошая поддержка со стороны TeamCity, который является сервером CI, который я использовал. Если Вы начинаете использовать MSBuild, и Вы хотите сделать больше пользовательских вещей в своем процессе сборки, добраться Задачи Сообщества MSBuild . Они дают Вам набор хороших дополнительных задач. Я не использовал NAnt в течение нескольких лет теперь, и я не сожалел о нем.
кроме того, как Ruben упоминает, существует Задачи SDC задачи на CodePlex.
еще для большего количества забавы, существует Пакет Расширения MSBuild на CodePlex, который включает задачу Твиттера.
Я использую MSBuild рядом Nant, потому что текущая версия Nant не может пока еще скомпилировать.NET 3,5 приложения (то же было верно, когда.NET 2,0 первых вышла).
Единственная причина I видит для использования msbuild, то, если требуется использовать автоматизированный сервер сборки как круиз-контроль. Если бы Вы не собираетесь переключаться, то я оставил бы его в покое.
Главная причина я все еще использую nAnt по msbuild для моих автоматизированных сборок, состоит в том, что у меня есть более тонкая настройка на моих сборках. Из-за msbuild, который имеет использование csproj, это - файл типа "build", весь источник в том проекте компилируется в один блок. Который заставляет меня иметь много проектов в моем решении для крупных проектов, где я разделяю логику. Хорошо с nant, я могу расположить свою сборку, где я могу скомпилировать то, что я хочу в несколько блоков от одного проекта.
мне нравится этот маршрут, потому что он мешает мне иметь во многие файлы проекта в моем решении. Я могу иметь один проект с папками, разделяющими слои, и затем использовать nant для встраивания каждого слоя в свой собственный блок.
Однако я действительно использую и nant и msbuild в соединении для некоторых задач сборки, как создание приложений WPF. Просто намного легче скомпилировать приложение WPF с целью msbuild в nant.
Для окончания это и точка моего ответа - то, что мне нравится использовать их рядом, но когда я использую msbuild в этой конфигурации, это обычно для прямой компиляции, не выполнения любых задач автоматизации сборки как копирование файлов к каталогу, генерация документации справки или выполнение моих модульных тестов, например.
Мы также переключились от nant до msbuild. Если Ваша сборка будет довольно стандартной, то у Вас не будет больших проблем при установке ее, но если у Вас есть много определенных задач сборки, необходимо будет записать пользовательские задачи сборки мс, поскольку существует путь меньше пользовательских задач для msbuild.
, Если Вы хотите отобразить разумные результаты сборки, необходимо будет смешать с пользовательскими регистраторами и т.д. Целая сборка команды не так готова, как nant.
, Но реальная выгода интеграция с управлением исходным кодом TFS и созданием отчетов о сервисах. Если Вы не используете TFS в качестве Своей системы управления исходным кодом, это не стоит того.
Я на самом деле все еще пытаюсь изобразить этот вопрос сам, но существует одна большая премия для MSBuild здесь: использование того же файла типа "build" для локальной непрерывной интеграции путем вызова msbuild.exe непосредственно, в то время как также способность использовать серверную сторону VSTS непрерывная интеграция с тем же файлом типа "build" (хотя наиболее вероятные различные свойства/настройки).
т.е. по сравнению с поддержкой TeamCity сценариев MSBuild, VSTS [только 110] поддержки сценарии MSBuild! Я бездельничал это в прошлом exec'ing NAnt из MSBuild; я видел, что другие рекомендуют эту практику, а также реверс, но это просто кажется kludgey мне, таким образом, я пытаюсь не сделать это, если я могу избежать его. Так, когда Вы используете "полный стек Microsoft" (VSTS и TFS), я предложил бы просто придерживаться сценариев MSBuild.
Рапа @Brad
я обычно не переключался бы между ними, если не была востребованная функция, которая пропускала
, что неопровержимые доводы должны использовать msbuild? есть ли недостатки?
До сих пор я получаю довольно хорошее, "не не беспокойтесь" из Вашего ответа.
NAnt был вокруг дольше и является значительно более сформировавшимся продуктом и также IMO, легче использовать. Существует большое общественное ноу-хау там для наслаждения, и это является также межплатформенным, должны Вы интересоваться созданием приложений, которые могут работать под Моно, а также.NET и Silverlight. Из поля это делает намного больше, чем MSBuild. Ах да, и можно назвать MSBuild от NAnt (хорошо, от NAntContrib) :-)
На отрицательной стороне, NAnt и его дочернем проекте, NAntContrib, действительно кажется, застоялись, при этом новое обновление в конце 2007.
основные преимущества, которые я вижу MSBuild, состоят в том, что он поставлется с Платформой.NET, таким образом, это - то меньше продукта для установки; и существует продолжение более активной разработки (хотя в местах для достижения уровня более старого NAnt).
Лично, я нахожу его синтаксис немного более трудным взять, но затем я уверен, что длительное воздействие ti сделало бы вещи легче.
Заключение? Если Вы работаете с существующими сценариями NAnt, палкой с ними, это не стоит стычки портирования. Если Вы запускаете новый проект, и Вы чувствуете себя предприимчивыми, то даете MSBuild движение.
Наиболее неопровержимый довод для использования MSBuild (по крайней мере, в.NET 3.5 и вне) - механизм сборки может создать одновременно.
Это означает, что огромная скорость в Ваших сборках в Вас имеет несколько ядер/процессоров.
До 3,5, MSBuild не сделал параллельных сборок.
Я чувствую, что MSBuild и Nant довольно сопоставимы. Если бы Вы используете один из них, я обычно не переключался бы между ними, если не была востребованная функция, которая отсутствовала в продукте, который Вы выбрали.
я лично использую MSBuild для любого нового проекта, но Ваш пробег может варьироваться.
Hope, которая помогает!
Редактирование: @ChanChan - @Jon упоминает, что Nant не создает.NET 3,5 приложения. Это может быть действительно причиной или изменить, или по крайней мере использовать их параллельно. Поскольку я переместился больше к MSBuild, я - вероятно, не самый информированный человек для выделения любого другого showstoppers с любой технологией.
Редактирование: кажется, что Nant теперь создает.NET 3.5 Приложения.
Мой совет является совсем противоположным - Избегают MSBuild как чумы. NANT далеко намного легче настроить Вашу сборку, чтобы сделать автоматическое тестирование, развернуться к нескольким продуктивным средам, интегрироваться с cruisecontrol для среды записи, интегрироваться с управлением исходным кодом. Мы прошли такую боль с TFS/MSBuild (Используя TFSDeployer, пользовательские powershell сценарии, и т.д.), чтобы заставить его делать то, что мы смогли сделать с NANT из поля. Не тратьте впустую свое время.
Я думаю, что они относительно сопоставимы и в функциях и в простоте использования. Только от того, чтобы быть C# базировался, я нахожу msbuild легче работать с, чем nants, хотя это - едва неопровержимый довод для переключателя.
, Что такое точно nant, не делающий для Вас? Или Вы просто надеетесь, что существует некоторая замечательная функция, которую можно пропускать?:)
Одна суперхорошая вещь о C# состоит в том, что, если у Вас есть .net платформа, у Вас есть все, что необходимо выполнить msbuild. Это фантастически, когда Вы работаете над многочисленными командами / проекты и имеете людей/аппаратные средства оборот.
Лично я предпочитаю SCons по ним обоим:)
Nant имеет больше функций из поля, но MSBuild имеет намного лучшую фундаментальную структуру (скалы метаданных объекта), который делает намного легче создать допускающие повторное использование сценарии MSBuild.
MSBuild требует времени для понимания, но после того как Вы делаете это очень хорошо.
Учебные материалы:
- В Microsoft Build Engine: Использование MSBuild и сборки основы команды
Sayed Ibrahim Hashimi (Jan, 2009) - Развертывание приложений.NET: изучение MSBuild и ClickOnce Sayed
Y. Hashimi (сентябрь 2008)
Я не вижу смысла переключаться. Сама MsBuild фиксирует вас в используемой вами структуре. Если вы используете NAnt, вы можете использовать его во многих фреймворках и использовать оболочку для msbuild, чтобы фактически выполнить задачу сборки за вас.
Я поклонник NAnt в этом отношении, потому что он немного отделяет вас от фреймворка.
Я создал фреймворк, который объединяет соглашения в автоматизированные сборки, и построил его на NAnt. Он называется UppercuT, и это безумно простая в использовании среда сборки.
Автоматизированная сборка - это просто: (1) имя решения, (2) путь управления версиями, (3) название компании для большинства проектов!
http: / /code.google.com/p/uppercut/[12171 visibleНекоторые хорошие объяснения: UppercuT
- Don't switch unless you have a very convincing reason (at least).
- NAnt is open source and if it weren't I wouldn't be able to customize our build system, MSBuild is not.
- NAnt can easily run MSBuild, I'm not sure about the other way around.
- MSBuild scripts are already written for you if you use VS2005 or newer (the project files are MSBuild files.)
- If you use NAnt, and you use VS to edit project files, settings and configurations, you'll have to write a converter/sync tool to update your NAnt files from the VS Project files.
Интеграция MSBuild с Visual Studio позволяет программистам меньше беспокоиться при использовании системы сборки. В основном это сводится к тому, что им нужно только выбрать «Построить решение», и все это работает, вместо того, чтобы использовать пользовательские шаги сборки и другие подобные вещи, или, что еще хуже, заставлять разработчиков строить путем запуска какого-то внешнего скрипта.
Сейчас я в основном предпочитаю MSBuild NAnt, потому что это проще. Конечно, у NAnt намного больше возможностей, он более мощный и т. Д., Но он может быстро выйти из-под контроля. Если у вас и ваших инженеров по сборке есть дисциплина, чтобы делать сценарии NAnt простыми, тогда все хорошо. Однако я видел слишком много систем, основанных на NAnt, которые уходили на юг до точки, когда никто больше не понимал, что они делают, и нет реального способа отладить это, кроме как сделать эквивалент старого доброго. printf. В тот момент, когда вы начинаете использовать какой-нибудь оператор if / else или цикл for, вот где, IMHO, он начинает пахнуть.
С другой стороны, MSBuild имеет прочную основу, основанную на метаданных и менее подробном синтаксисе. Его простота (или отсутствие функций ... в зависимости от того, как вы это видите) заставляет вас писать логику в .NET-коде с помощью новых задач вместо того, чтобы писать логику в разметке XML. Это способствует повторному использованию и, прежде всего, позволяет вам отлаживать вашу систему сборки в реальном отладчике.
Единственная проблема с MSBuild - это не очень случайная ошибка (особенно в первой версии) или непонятная (хотя задокументированное) поведение. И, если это действительно беспокоит вас, привязанность к Microsoft.
С другой стороны, MSBuild имеет прочную основу, основанную на метаданных и менее подробном синтаксисе. Его простота (или отсутствие функций ... в зависимости от того, как вы это видите) заставляет вас писать логику в .NET-коде с помощью новых задач вместо того, чтобы писать логику в разметке XML. Это способствует повторному использованию и, прежде всего, позволяет вам отлаживать вашу систему сборки в реальном отладчике.
Единственная проблема с MSBuild - это не очень случайная ошибка (особенно в первой версии) или непонятная (хотя задокументированное) поведение. И, если это действительно беспокоит вас, привязанность к Microsoft.
С другой стороны, MSBuild имеет прочную основу, основанную на метаданных и менее подробном синтаксисе. Его простота (или отсутствие функций ... в зависимости от того, как вы это видите) заставляет вас писать логику в .NET-коде с помощью новых задач вместо того, чтобы писать логику в разметке XML. Это поощряет повторное использование и, прежде всего, позволяет вам отлаживать вашу систему сборки в реальном отладчике.
Единственная проблема с MSBuild - это не очень случайная ошибка (особенно в первой версии) или неясная (хотя задокументированное) поведение. И, если это действительно беспокоит вас, привязанность к Microsoft.
Это способствует повторному использованию и, прежде всего, позволяет вам отлаживать вашу систему сборки в реальном отладчике.Единственная проблема с MSBuild - это не очень случайная ошибка (особенно в первой версии) или непонятная (хотя задокументированное) поведение. И, если это действительно беспокоит вас, привязанность к Microsoft.
Это поощряет повторное использование и, прежде всего, позволяет вам отлаживать вашу систему сборки в реальном отладчике.Единственная проблема с MSBuild - это не очень случайная ошибка (особенно в первой версии) или неясная (хотя задокументированное) поведение. И, если это действительно беспокоит вас, привязанность к Microsoft.
Я перешел с NANT на MSBuild. Проект работает в .Net 4.0.
Мой опыт работы в NANT был хорошим. Проект как бы умер. И когда появился .Net 4.0, пришло время заново оценить процесс сборки.
С тех пор, как Nant был выпущен в последний раз, MSBuild прошел долгий путь. На данный момент MSBuild - это то, что нужно. Он прост в использовании, имеет множество расширений. Я переписал свои скрипты Nant за полтора дня. Скрипт MSBuild на 1/3 меньше скриптов Nant.
Большая часть работы в сценарии Nant заключалась в настройке различных окружений. В MsBuild/.Net 4.0 она встроена.