Будет ли MSBuild мертвым из-за Windows Workflow?

MSBuild в TFS 2010 был заменен Windows Workflow 4.0. Это означает, что когда вы создаете определение сборки, у вас не будет TFSBuild.proj для редактирования, вместо этого вы должны отредактировать рабочий процесс, чтобы настроить свою сборку.

Я верю, если я скажу, что Microsoft не поддерживает MSBuild в TFS 2010, а обучение MSBuild в качестве администратора Team Team Team TFS 2010 не стоит?

И еще один вопрос: является ли Microsoft заменять язык Visual Studio Projects от MSBuild на что-то вроде Windows Workflow?

ОТВЕТЫ

Ответ 1

Я - Менеджер программ для функций автоматизации сборки TFS, поэтому я хотел бы прокомментировать этот вопрос. Мы не заменили MSBuild на Windows Workflow (WF). Мы все еще очень полагаемся на MSBuild в качестве основного механизма сборки, который является его основной компетенцией. Вы обнаружите, что есть множество задач, которые все еще наиболее легко и эффективно автоматизируются с помощью MSBuild.

Мы внедрили WF как способ обеспечения уровня более высокого уровня взаимодействия над процессором ядра (который является MSBuild в шаблонах процесса сборки, которые мы включаем в поле). Это позволяет делать такие вещи, как распространение процесса на нескольких компьютерах и привязка процесса к другим процессам на основе процессов.

Итак, когда вы должны автоматизировать работу с MSBuild и когда вы должны автоматизировать WF? Вот мое общее руководство по этому вопросу:

  • Если задача требует знания конкретных входов или выходов сборки, используйте MSBuild
  • Если задача - это что-то, что вам нужно сделать при создании в Visual Studio, используйте MSBuild
  • Если задача - это то, что вам нужно только при создании на сервере сборки, используйте WF, если только для этого не требуется знание конкретных входов/выходов сборки

При использовании MSBuild помните, что вы можете напрямую настроить файлы проекта (разгружая их, а затем редактировать их в Visual Studio), или вы можете создавать пользовательские файлы .targets и импортировать их в свои отдельные проекты. Последний подход полезен для функциональности, присущей нескольким проектам, чтобы не поддерживать несколько копий.

При использовании WF помните, что вы можете писать операции с кодом для низкоуровневых задач, но вы также можете создавать задачи более высокого уровня, используя прямой XAML. Мы фактически работаем над версией шаблона процесса построения по умолчанию, который поставляется с TFS 2010, который дает вам более простой и менее подробный вид всего процесса с использованием набора составных действий XAML.

Ответ 2

Я не думаю, что MSBuild будет заменен workflow 4.0, скорее я думаю, что обе эти технологии будут дополнять друг друга и будут существовать вместе. Будет какая-то категория задач, которые легче выполнять в MSBuild, чем рабочий процесс. Поэтому люди собираются использовать MSBuild для некоторого набора и рабочего процесса для другого набора. Поэтому в некотором смысле это будет сочетание как рабочего процесса, так и MSBuild.

Кстати, Tfs 2010 поддерживает MSBuild с помощью шаблона обновления. И я не думаю, что рабочий процесс может заменить MSBuild на языке Visual Studio Projects.