Получать выходные файлы из проекта MSBuild

Можно ли получить список всех всех выходных файлов из проекта MSBuild?

В простом проекте я мог бы сделать что-то вроде

<CreateItem Include="$(OutputDir)**\*">
      <Output ItemName="AllOutputs" TaskParameter="Include"/>
</CreateItem>

но мои проекты являются частью более крупной сборки, и все выходы идут в общее место, я хочу иметь возможность excllde dlls и контента, которые не принадлежат.

Любые идеи?

Ответы

Ответ 1

После того, как я снова посмотрел на ваш комментарий, я понял, что я неправильно понял, что вам действительно нужно. Это интересная проблема, которая у вас на руках.

Если вы не возражаете редактировать файл проекта, вы можете получить красивое закрыть, что хотите. Существует элемент FileWrites, который отслеживает все файлы, которые были выписаны во время процесса сборки. Чтобы начать играть с этим редактированием файла проекта, для этого AfterBuild target

<Target Name="AfterBuild">
  <Message Text="FileWrites: @(FileWrites)" Importance="high"/>
</Target>

Есть некоторые проблемы с этим подходом, а также

  • Вам нужно самому отредактировать файл проекта
  • Это будет содержать файлы, записанные в промежуточный выходной каталог (т.е. obj) и выходной каталог (т.е. bin)
  • Если есть встроенные настройки, они не обязаны записывать этот элемент

Возможно, вы можете решить первую проблему с помощью метода MSBuild: Find Many Project References и вывести элемент FileWrites после выполнения сборки, Это будет работать только в том случае, если файл proxy-оболочки был помещен в ту же папку, что и исходный проект, потому что все элементы внутри файла .csproj объявлены с относительным путем. Так что по большей части это происходит.

Вы можете получить второе ограничение, используя задачу FindUnderPath, чтобы получить файлы, помещенные в папку OutputPath.

То, что вы могли бы сделать, но не очень надежное, - это изучить OutputPath в начале сборки, а затем еще раз в конце сборки увидеть, что было добавлено. Скажем, что вы поместили исходные файлы в элемент StartFiles и в конце сборки поместили все файлы в элемент EndFiles, который вы могли бы сделать:

<Target Name="SomeTargetHere">

<ItemGroup>
    <FilesWritten Include="@(EndFiles)" />
    <FilesWritten Remove="@(StartFiles)"/>
</ItemGroup>

<!-- Now FilesWritten contains the difference between EndFiles & StartFiles -->

</Target>

Короче, я не уверен, есть ли хорошее решение, которое не включает в себя ни настраиваемую задачу, ни пользовательский журнал: (.

Сказал Ибрагим Хашими

Моя книга: Внутри Microsoft Build Engine: использование MSBuild и Team Foundation Build

Ответ 2

Если вы используете задачу MSBuild, вы можете получить файлы, которые были созданы с использованием вывода TargetOutputs. Вот пример

<MSBuild Projects="YourProject.csproj">
      <Output ItemName="YourProjectOutputs" TaskParameter="TargetOutputs"/>
</MSBuild>

Итак, в этом случае, когда построено YourProject.csproj, созданные файлы будут помещены в элемент YourProjectOutputs.

Я создал запись в блоге некоторое время назад, которая более подробно рассказывает об этом, MSBuild: как получить все генерируемые выходы.

Сказал Ибрагим Хашими

Моя книга: Внутри Microsoft Build Engine: использование MSBuild и Team Foundation Build

Ответ 3

Взгляните на мою предыдущую запись в блоге MSBuild: найдите много ссылок на проекты. В этой статье я описываю, как вы можете создать файл MSBuild, который мог бы извлечь значения для Reference ItemGroup. В вашем случае просто замените цель, которую я создал, с той, которая заполняет элемент из всех файлов, найденных в OutputPath. Дайте мне знать, если вы хотите, чтобы я расширил это.

Ответ 4

Что мы делаем в этом сценарии, так это то, что каждая сборка создает каталог "Развертывание" (вы можете называть его тем, что захотите).

Каталог развертывания содержит только те исполняемые файлы и библиотеки, которые необходимы для фактического приложения (т.е. тестирование DLL не попадает туда). Каждый проект должен будет получить свой "Развертываемый" материал в этот каталог (мы даже добавляем подкаталоги (например, Web, Services и т.д.).

Он дублирует некоторые биты, но позволяет вам иметь доступ ко всем DLL файлам из сборки, если они необходимы.