2009-06-26 13 views
15

È possibile ottenere un elenco di tutti i file di output da un progetto MSBuild?Ottenere file di output da un progetto MSBuild

In un progetto semplice, ho potuto fare qualcosa di simile

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

ma i miei progetti sono parte di una costruzione più grande, e tutte le uscite andare a una posizione comune, voglio essere in grado di exculde DLL e contenuti che non appartengono

Qualche idea?

risposta

23

Dopo aver esaminato di nuovo il tuo commento mi sono reso conto di non aver interpretato correttamente ciò di cui avevi davvero bisogno. Questo è un problema interessante che hai tra le mani.

Se non ti dispiace modificare il file di progetto stesso, potresti essere in grado di ottenere un bel vicino a per quello che vuoi. C'è un articolo FileWrites che tiene traccia di tutti i file che sono stati scritti durante il processo di compilazione. Per iniziare a giocare con questo modificare il file di progetto di avere questo obiettivo AfterBuild

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

Ci sono alcuni problemi con questo approccio così

  • È necessario modificare il file di progetto stesso
  • Ciò conterrà i file scritti nella directory di output intermedio (ovvero obj) e la directory di output (ovvero bin)
  • Se ci sono costruire le personalizzazioni, essi non sono tenuti a scrivere a questa voce

Si potrebbe pensare che si potrebbe risolvere il primo problema con il MSBuild: Find Many Project References tecnica e uscita la voce FileWrites dopo aver fatto una generazione. Questo funzionerà solo se il file wrapper proj è stato inserito nella stessa cartella del progetto originale stesso perché tutti gli elementi all'interno di un file .csproj sono dichiarati con un percorso relativo.Quindi ci va per la maggior parte.

È possibile superare la seconda limitazione utilizzando l'attività FindUnderPath per ottenere solo i file inseriti nella cartella OutputPath.

Quello che potresti fare ma non è realmente affidabile è esaminare l'OutputPath all'inizio della compilazione e poi ancora una volta alla fine della build e vedere cosa è stato aggiunto. Diciamo che si mette i file originali in un elemento startfile e alla fine della compilazione mettono tutti i file in una voce denominata EndFiles si potrebbe il fai:

<Target Name="SomeTargetHere"> 

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

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

</Target> 

Insomma io non sono sicuro se c'è una buona soluzione che non comporta né un'attività personalizzata o un :(logger personalizzato

Sayed Ibrahim Hashimi

My Book:. Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

+0

Grazie per la risposta dettagliata. –

11

Se si utilizza MSBuild task, è possibile ottenere i file creati utilizzando l'output TargetOutputs. Ecco un esempio

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

Quindi, in questo caso, quando YourProject.csproj è costruito i file che sono stati creati verrebbero collocati all'interno delle YourProjectOutputs voce.

Ho creato un post di blog qualche tempo fa che parla più dettagliatamente di questo, MSBuild: How to Get All Generated Outputs.

Sayed Ibrahim Hashimi

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

+0

Grazie per il suggerimento, il problema è che TargetOutputs include solo l'assembly di output e l'attività GetOutputs include tutto nella directory di output, anche se il progetto msbuild non lo ha creato/copiato. –

3

Date un'occhiata al mio precedente blog MSBuild: Find Many Project References. In questo post descrivo come è possibile creare un file MSBuild in grado di estrarre i valori per il gruppo di riferimento. Nel tuo caso basta sostituire il target che ho creato con uno che ha popolato un oggetto da tutti i file trovati in OutputPath. Fammi sapere se vuoi che io espandi questo.

0

quello che facciamo il combattimento in questo scenario è che ogni generazione crea un regista "Deploy" y (puoi chiamarlo come vuoi tu).

La directory di distribuzione contiene solo quegli eseguibili e DLL necessari per l'app effettiva (ovvero, le DLL di test non vengono inserite lì). Ogni progetto dovrebbe avere la sua roba "deployabile" in quella directory (aggiungiamo anche sottodirectory (ad esempio, Web, servizi, ecc.)

Duplica alcuni bit, ma consente di accedere a tutte le DLL da un costruire se sono necessari.

+0

Desidero avere una directory "Deploy" comune, ma essere in grado di determinare quali file vengono creati da ciascun progetto –

Problemi correlati