Obtener archivos de salida de un proyecto de MSBuild

Question

¿Es posible obtener una lista de todos los archivos de salida de un proyecto de MSBuild?

En un proyecto simple, podría hacer algo como

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

pero mis proyectos son parte de una estructura más grande, y todas las salidas de ir a un lugar común, quiero ser capaz de exculde dlls y contenidos eso no pertenece.

¿Alguna idea?

Answer 1

Después de ver tu comentario de nuevo me di cuenta de que malinterpreté lo que realmente necesitabas. Este es un problema interesante que tienes en tus manos.

Si no te importa editar el archivo del proyecto en sí mismo, puedes obtener cerca de a lo que quieras. Hay un elemento FileWrites que realiza un seguimiento de todos los archivos que se escribieron durante el proceso de compilación. Para empezar a jugar con esta edición del archivo de proyecto para tener este AfterBuild objetivo

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

Hay algunos problemas con este enfoque, así

• Tiene que editar el archivo de proyecto en sí
• Esto contendrá los archivos escritos en el directorio de salida intermedio (es decir, obj) y el directorio de salida (es decir, bin)
• Si hay construir personalizaciones, que no están obligados a escribir en este artículo

Se podría pensar que se podía resolver el primer problema con el MSBuild: Find Many Project References técnica y la salida del elemento FileWrites después de hacer una compilación. Esto solo funcionará si el archivo de proyecto de envoltura se colocó en la misma carpeta que el proyecto original en sí porque todos los elementos dentro de un archivo .csproj se declaran con una ruta relativa.Así que ahí va eso en su mayor parte.

Puede superar la segunda limitación utilizando la tarea FindUnderPath para obtener solo los archivos colocados en la carpeta OutputPath.

Lo que podría hacer, pero no es realmente confiable, es examinar OutputPath al comienzo de la compilación y, una vez más, al final de la compilación, ver lo que se agregó. Digamos que usted pone los archivos originales en una ficheros de inicio del artículo y al final de la acumulación de poner todos los archivos en un artículo llamado EndFiles se podía el do:

<Target Name="SomeTargetHere"> 

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

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

</Target> 

En resumen no estoy seguro de si hay una buena solución que no implique ya sea una tarea personalizada o una :(anotador personalizado

Sayed Ibrahim Hashimi

Mi libro:. Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

Answer 2

Si está utilizando el MSBuild task entonces se puede obtener los archivos que se generan utilizando la salida TargetOutputs. Aquí está un ejemplo

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

Así que en este caso cuando YourProject.csproj se construye los archivos creados se coloca dentro de la YourProjectOutputs artículo.

He creado una entrada de blog hace un tiempo que habla con más detalle acerca de esto, MSBuild: How to Get All Generated Outputs.

Sayed Ibrahim Hashimi

Mi libro: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

Answer 3

Tome un vistazo a mi anterior entrada del blog MSBuild: Find Many Project References. En esa publicación, describo cómo puedes crear un archivo MSBuild que pueda extraer los valores para el ItemGroup de referencia. En su caso, simplemente reemplace el objetivo que creé con uno que llenó un elemento de todos los archivos encontrados en OutputPath. Avísame si quieres que lo amplíe.

Answer 4

lo que hacemos el combate de este escenario es que cada generación crea un director de "Desplegar" y (puedes llamarlo como quieras).

El directorio de despliegue contiene sólo los archivos ejecutables y archivos DLL que son necesarios para la aplicación real (es decir, archivos DLL de prueba no se les puso en su lugar). Cada proyecto necesitaría tener sus cosas "Desplegables" en ese directorio (incluso agregamos subdirectorios (es decir, Web, Servicios, etc.).

Duplica algunos bits, pero le permite tener acceso a todos los dlls desde un construir si son necesarios.