Как эмулировать параметр / p msbuild в сборке Visual Studio?

Question

Это логическое продолжение моего предыдущего вопроса: « Как проверить все проекты в решении по некоторым критериям? »
Мне дали довольно хороший ответ на использование CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets.Они работают, поэтому я решил не останавливаться на достигнутом.

Проблема в том, что я не хочу задач на уровне машины.Это не очень хорошая идея ни для меня (это повлияет на другие сборки. Конечно, это можно сделать, но все же), ни для моих товарищей по команде (я не хочу, чтобы они что-то помещали в системные папки ...), нидля сборки сервера.Что необходимо: решение, которое будет построено с нуля из-под контроля исходного кода на чистой машине с Visual Studio или MSBuild.

Оказалось, что Custom * MicrosoftCommonTargets - это обычные свойства.

Итак, как указать это свойство?Это работает довольно хорошо, когда установить его из командной строки.Это странно, но кажется, что здесь есть немного волшебства: свойство, переданное как параметр командной строки одной сборке, транзитивно , переданное всем вложенным сборкам!

Это нормальнодля сборки сервера.Но это не будет работать со сборкой Visual Studio.И даже объявление свойства уровня решения не поможет: ни статические, ни динамические свойства не передаются во вложенные сборки.

... У меня есть хакерская идея установить переменную среды перед сборкой решения и стереть ее после.Но мне это не нравится.Есть идеи получше?

Answer 1

Я использую немного другую технику, чем @Spider M9.Я хочу, чтобы все проекты в дереве решений / всех подкаталогах из текущего каталога использовали расширенный сборочный бросок Custom * MicrosoftCommonTargets.Мне не нравится, когда меня заставляют менять каждый новый проект для импорта пользовательских целей / реквизита.

Я помещаю специальный файл, скажем, msbuild.include , в корневой каталог, и мой загрузчик пользовательских целей для каждого проекта пытается найти его в . , * 1007.* .. \ , .. \ .. \ и т. Д.msbuild.include содержит флаги, которые запускают выполнение пользовательских действий.Если загрузчик не может найти этот файл, он отключает загрузку всех пользовательских целей и остановок.Это дает мне возможность использовать мои расширения сборки с проектами из рабочих репозиториев и не использовать с проектами с открытым исходным кодом.

Если вы заинтересованы, я могу опубликовать загрузчик.Это довольно простое и элегантное решение.

Например, я могу подписать любую сборку во всех проектах во всех подпапках своим ключом.

Answer 2

Я всегда настраивал каждый проект на импорт стандартного файла .props. Используйте функцию свойства GetDirectoryNameOfFileAbove (см. MSDN), чтобы найти ее. Сделайте это в качестве первой строки каждого файла проекта. После установки вы можете перенаправить из этого файла в другой импорт. Другая хитрость заключается в том, чтобы этот стандартный импорт (который, очевидно, находился бы под контролем версий) импортировал условно другой файл .props, только если он существует. Этот необязательный файл не будет находиться под управлением версией, но доступен для любого разработчика для создания и изменения с использованием собственных / временных свойств или другого поведения.