Ответ 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.