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

Question

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

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

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

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

Есть идеи?

Answer 1

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

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

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

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

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

Вы можете подумать, что могли бы решить первую проблему с помощью метода MSBuild: найти множество ссылок на проекты и вывести элемент FileWrites после выполнения сборки. Это будет работать только в том случае, если proj-файл оболочки был помещен в ту же папку, что и сам исходный проект, поскольку все элементы в файле .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

Answer 2

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

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

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

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

Сайед Ибрагим Хашими

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

Answer 3

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

Answer 4

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

Каталог deploy содержит только те исполняемые файлы и библиотеки DLL, которые необходимы для реального приложения (т. Е. Тестовые библиотеки не помещаются туда). Каждый проект должен будет поместить свои «развертываемые» материалы в этот каталог (мы даже добавляем подкаталоги (например, Web, Services и т. Д.).)

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