Как программно отменить встроенную сборку MsBuild

Question

Я встраиваю MSBuild непосредственно в более сложный инструмент сборки. Соответствующий код выглядит примерно так:

// assume 'using Microsoft.Build.BuildEngine;'
Engine e = Engine();
BuildPropertyGroup props = new BuildPropertyGroup();
props.SetProperty( "Configuration", Config.BuildConfig );
e.BuildProjectFile( projectFile, new string[] { "Build" }, props )

Мой вопрос заключается в том, как отменить сборку после ее запуска, не делая ничего радикального, например, завершение потока. Кроме того, если создаваемый проект является проектом C ++, сборка будет включать, по крайней мере, один подпроцесс, поэтому отмена потока даже не приведет к реальной отмене сборки.

Я не вижу метода отмены в классе Engine - кто-нибудь знает способ?

Answer 1

Этот вопрос несколько раз поднимался на платах MSDN, и, к сожалению, я не видел другого пути, кроме завершения потока. К сожалению, в этом случае завершение потока не так уж и сильно, так как это единственная реальная возможность.

На случайной стороне, я не уверен, в какой степени вы используете MSBuild с тем, что вы делаете в настоящее время. Просто хотел порекомендовать взглянуть на MSBuild Extension Pack на Codeplex, если вы регулярно работаете с MSBuild.

Answer 2

Похоже, что нет официального способа сделать это.

Для сборок на C # это не так уж и сложно, так как они обычно бывают очень быстрыми. Лучший обходной путь, который я нашел для сборки C ++, - это найти дочерние процессы, созданные процессом сборки VC, и завершить их, что останавливает сборку MSBuild. Это можно сделать с помощью снимка Toolhelp32, что-то вроде этого (без мусора P / Invoke):

CreateToolhelp32Snapshot( ToolHelp.SnapshotFlags.Process, 0 );

Отсюда вы можете определить родительские / дочерние отношения между процессами и найти процессы, порожденные приложением, которое вызывает MSBuild.

Answer 3

Я сделал нечто подобное, запустив msbuild из команды. Это запускает процесс, который вы можете прекратить.

Исходя из моего опыта, гораздо проще и гибче манипулировать файлами проекта с помощью инструментов xml и затем выполнять msbuild, чем программно конфигурировать ваши проекты так, как вы описали. Это также более управляемо.