Как проверить все проекты в решении по некоторым критериям?

Question

Мне нужно, чтобы все проекты в решении содержали некоторые дополнительные действия по сборке, например, проверку StyleCop, автогенерацию AssemblyInfo и т. Д.

Моя идея состоит в том, чтобы создать какое-то событие предварительной сборки для решения, которое проверит всефайлы проекта для размещения узлов, которые соответствуют определенному xPath.Это не сложная часть, ее можно решить либо с помощью пользовательской задачи сборки, либо с помощью какой-либо сторонней задачи обработки Xml.Я еще не исследовал это глубоко, но это определенно не сделает проблему достойной упоминания здесь.

Вопрос в том, как
1) расширить файл решения некоторыми пользовательскими задачами?Это не должно быть необходимой неотъемлемой частью решения.Это желательно, но может быть опущено при сборке из VS, будет достаточно иметь определенную командную строку, которая его выполняет.
2) если это невозможно, есть опция, описанная в " pre-wide-preсобытие?".Это хакерство, но если других вариантов нет, я воспользуюсь им.Но как получить список файлов проекта из файла решения?Пожалуйста, примите во внимание, что папка, содержащая решение, может содержать дополнительные файлы проекта, которые не должны проверяться, поэтому просто перечислите все ***. * Proj не вариант.

PS Любые другие варианты для всей проблемытоже приветствуются:)

Answer 1

Вы можете создавать любые пользовательские задачи с любыми условиями, используя встроенную функцию MSBuild для расширения функциональности: CustomAfterMicrosoftCommonTargets , CustomBeforeMicrosoftCommonTargets .

См. Мой пример .Вы можете добавлять собственные задачи в файл .targets для каждого шага процесса сборки.Вы можете добавить условия для включения / выключения этих действий и так далее.Он не зависит от файла sln, но у вас могут быть задачи, которые будут зависеть от VS с условием '$ (BuildingInsideVisualStudio)' == 'true' .Вы можете вызывать их из командной строки - вам нужно указать имя цели с помощью ключа / t: MyCustomTarget .

Побочные эффекты: если у вашей пользовательской цели не будет каких-либо особых условий - этобудет вызываться в каждом подобном проекте.

Answer 2

Я никогда не подходил к этой проблеме с уровня решения - у вас нет большого контроля при вызове msbuild для файла решения.

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

<Import Project="_pathToCommonTargets_" />

После импорта общих целей вы можете контролировать то, что происходит с перехватчиками в проекте сборки - то есть перезаписываемые цели, которые возникают в определенных точках, когда в этом проекте вызывается «Build». Кроме того, вы можете создавать новые цели в файле общих целей, который можно просто вызывать вместо цели сборки, когда вы строите вне Visual Studio.

<Target Name="AfterBuild" >
  <!-- Other tasks here -->
  <!-- Calling a common target -->
  <CallTarget Target="_commonTargetName_" />
</Target>

Кроме того, я бы не рекомендовал использовать что-то вроде XPath для определения узлов в каждом файле проекта. Было бы намного чище использовать функции, встроенные в msbuild. Например, вы можете проверить, установлены ли свойства (дочерние элементы узлов propertyGroup) и выполнить операции с коллекциями (дочерние элементы узлов itemGroup.)

• Домашняя страница Msbuild: http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx
• Msbuild переопределенных пользовательских целей: http://msdn.microsoft.com/en-us/library/aa337604.aspx

Answer 3

Существует гораздо более простой способ справиться с подобными вещами. Вместо того, чтобы пытаться динамически изменять содержимое файла проекта, вы можете использовать совместно используемые файлы сборки .targets, которые импортируются в ваши проекты Visual Studio с помощью механизма, описанного в http://msdn.microsoft.com/en-us/library/ms171464.aspx (с другим примером в http://msdn.microsoft.com/en-us/library/ms171464.aspx).