MSBuild non raccoglie i riferimenti del progetto referenziato

Question

Mi sono imbattuto in una strana situazione con MSBuild proprio ora. C'è una soluzione che ha tre progetti: LibX, LibY ed Exe. Riferimenti Exe LibX. LibX a sua volta fa riferimento a LibY, ha alcuni file di contenuto e fa anche riferimento a una libreria di terze parti (numerosi assembly preinstallati installati sia in GAC che nella cartella lib locale). La libreria di terze parti è contrassegnata come " Copia locale " (" private ") e appare nell'output del progetto LibX, come fanno l'output di LibY e i file di contenuto di LibX. Ora, l'output del progetto Exe ha l'output del progetto LibX, i file di contenuto del progetto LibX, l'output del progetto LibY (proveniente da LibX), ma nessun assemblaggio di librerie di terze parti.

Ora ho risolto il problema facendo riferimento alla libreria di terze parti direttamente nel progetto Exe, ma non credo che questo sia un "diritto". soluzione.

Qualcuno ha avuto questo problema prima?

Answer 1

Sì, ho avuto anche questo problema. Anche se mi piacerebbe dire diversamente, credo che tu debba includere tutte le dipendenze transitive come riferimenti nel tuo file di build.

Answer 2

Esiste una differenza nel comportamento durante la compilazione con MSBuild (ovvero riga di comando, TFS Build e altri strumenti) rispetto alla compilazione con Visual Studio. I riferimenti secondari non sono inclusi nella variabile riferimenti inviata nelle attività di compilazione di MSBuild.

Esistono diversi punti di estensione forniti da MSBuild per modificare le modalità di risoluzione dei riferimenti. Ho usato con successo AfterResolveReference per risolvere questo problema per alcuni dei miei progetti - Ho pubblicato maggiori informazioni sullo sfondo sul mio blog .

La soluzione alternativa è aggiungere il seguente codice nei file vbproj o csproj

  <Target Name="AfterResolveReferences">
    <!-- Redefine referencepath to add dependencyies-->
    <ItemGroup>
     <ReferencePath Include="@(ReferenceDependencyPaths)">
     </ReferencePath>
    </ItemGroup> 
  </Target>

Microsoft ha dichiarato che ciò non risolverà Connect

Answer 3

Puoi effettivamente andare nel file Microsoft.CSharp.targets o Microsoft.VisualBasic.targets (che si trova nella directory del framework, generalmente C: \ Windows \ Microsoft.NET \ Framework \ v3.5) e modificare il csc o il vbc parametri dell'attività per includere dipendenze di riferimento aggiuntive. Nel file (target VB, riga 166; target C #, riga 164) modifica: \

References="@(ReferencePath)"

a

References="@(ReferencePath);@(ReferenceDependencyPaths)"

Ciò potrebbe causare altri problemi a seconda di quanto siano complicate le cose e potrebbe giocare brutti scherzi con il compilatore inproc di Visual Studio, ma è l'unico modo per farlo in MSBuild che ho trovato.

Answer 4

la risposta di josant ha quasi funzionato per me; Continuavo a ricevere un errore in Visual Studio quando l'ho provato:

Si è verificato un problema durante il tentativo di impostare i riferimenti " Riferimenti " parametro per il compilatore in-process dell'IDE. Errore HRESULT E_FAIL è stato restituito da una chiamata a un componente COM

La soluzione al mio problema era quella di mettere una condizione sul gruppo di oggetti, in questo modo:

<Target Name="AfterResolveReferences">
  <!-- Redefine referencepath to add dependencies-->
  <ItemGroup Condition=" '$(BuildingInsideVisualStudio)' != 'true' ">
    <ReferencePath Include="@(ReferenceDependencyPaths)"></ReferencePath>
  </ItemGroup>
</Target>

Ciò ha fatto sì che Visual Studio ignorasse completamente la modifica del riferimento e la compilazione funzionasse correttamente localmente e sul server di compilazione.

Answer 5

Ho combinato soluzione con una soluzione che copia anche dll nativo .

Answer 6

Il metodo AfterResolveReferences fallisce se hai un grafico diretto non un albero con un "tentativo di distribuire diverse copie della dll" errore. (cfr. Come configurare msbuild / MSVC per distribuire file dipendenti di assembly dipendenti )