[visual-studio] MSBuild non copia i riferimenti (file DLL) se si utilizzano le dipendenze del progetto nella soluzione



7 Answers

Mi occupo solo di questo. Vai alle proprietà del tuo riferimento e fai questo:

Set "Copy local = false"
Save
Set "Copy local = true"
Save

e questo è tutto.

Visual Studio 2010 non viene inizialmente inserito: <private>True</private> nel tag di riferimento e l'impostazione "copy local" su false causa la creazione del tag. Successivamente lo imposterà su true e false di conseguenza.

Question

Ho quattro progetti nella mia soluzione di Visual Studio (ognuno con targeting per .NET 3.5). Per il mio problema, solo questi due sono importanti:

  1. MyBaseProject <- questa libreria di classi fa riferimento a un file DLL di terze parti (elmah.dll)
  2. MyWebProject1 <- questo progetto di applicazione web ha un riferimento a MyBaseProject

Ho aggiunto il riferimento elmah.dll a MyBaseProject in Visual Studio 2008 facendo clic su "Aggiungi riferimento ..." → scheda "Sfoglia" → selezionando "elmah.dll".

Le proprietà del riferimento Elmah sono le seguenti:

  • Alias: globale
  • Copia locale - vero
  • Cultura -
  • Descrizione - Moduli di gestione degli errori e gestori (ELMAH) per ASP.NET
  • Tipo di file - Assemblaggio
  • Percorso - D: \ webs \ otherfolder \ _myPath \ __ tools \ elmah \ Elmah.dll
  • Risolto - Vero
  • Versione runtime - v2.0.50727
  • Versione specificata - falso
  • Nome forte - falso
  • Versione - 1.0.11211.0

In MyWebProject1 ho aggiunto il riferimento a Project MyBaseProject di: "Aggiungi riferimento ..." → scheda "Progetti" → selezionando "MyBaseProject". Le proprietà di questo riferimento sono le stesse ad eccezione dei seguenti membri:

  • Descrizione -
  • Percorso: D: \ webs \ CMS \ MyBaseProject \ bin \ Debug \ MyBaseProject.dll
  • Versione - 1.0.0.0

Se eseguo la compilazione in Visual Studio il file elmah.dll viene copiato nella directory bin del mio MyWebProject1 , insieme a MyBaseProject.dll!

Tuttavia, se pulisco ed eseguo MSBuild per la soluzione (tramite D: \ webs \ CMS> C: \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ MSBuild.exe / t: ReBuild / p: Configuration = Debug MyProject.sln ) l' elmah.dll è mancante nella directory bin di MyWebProject1 - sebbene la build stessa non contenga avvisi o errori!

Ho già fatto in modo che il .csproj di MyBaseProject contenga l'elemento privato con il valore "true" (che dovrebbe essere un alias per " copy local " in Visual Studio):

<Reference Include="Elmah, Version=1.0.11211.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\mypath\__tools\elmah\Elmah.dll</HintPath>
    **<Private>true</Private>**
</Reference>

(Per impostazione predefinita, il tag privato non compariva nell'xml di .csproj, sebbene Visual Studio dicesse "copy local" vero. Ho cambiato "copy local" su false - saved - e lo ho impostato nuovamente su true - save!)

Cosa c'è di sbagliato in MSBuild? Come posso ottenere il riferimento (elmah.dll) copiato nel cestino di MyWebProject1?

NON voglio aggiungere un'azione di copia post-costruzione al comando postbuild di ogni progetto! (Immagina che molti progetti dipendano da MyBaseProject!)




La modifica del framework di destinazione da .NET Framework 4 Client Profile a .NET Framework 4 ha risolto il problema.

Quindi nel tuo esempio: imposta il framework di destinazione su MyWebProject1 su .NET Framework 4




Dare un'occhiata a:

Questa discussione sul forum MSBuild che ho avviato

Troverai la mia soluzione temporanea / soluzione qui!

(MyBaseProject ha bisogno di un codice che faccia riferimento ad alcune classi (qualunque) dal elmah.dll per elmah.dll che viene copiato nel cestino di MyWebProject1!)




Il problema che stavo affrontando era che ho un progetto che dipende da un progetto di biblioteca. Per costruire I seguivo questi passaggi:

msbuild.exe myproject.vbproj /T:Rebuild
msbuild.exe myproject.vbproj /T:Package

Questo ovviamente significava che mancavano i file dll della mia libreria in bin e, cosa più importante, nel file zip del pacchetto. Ho trovato questo funziona perfettamente:

msbuild.exe myproject.vbproj /T:Rebuild;Package

Non ho idea del motivo per cui questo lavoro o perché non lo ha fatto in primo luogo. Ma spero che aiuti.




Oggi ho avuto un problema simile, e questa non è certamente la risposta alla tua domanda. Ma mi piacerebbe informare tutti, e possibilmente fornire una scintilla di intuizione.

Ho un'applicazione ASP.NET. Il processo di compilazione è impostato per pulire e quindi creare.

Ho due script di Jenkins . Uno per la produzione e uno per la messa in scena. Ho implementato la mia applicazione per la messa in scena e tutto ha funzionato bene. Distribuito alla produzione e mancava un file DLL a cui si faceva riferimento. Questo file DLL era solo nella radice del progetto. Non in alcun repository NuGet. La DLL è stata impostata per do not copy .

Lo script CI e l'applicazione erano gli stessi tra le due distribuzioni. Ancora dopo la pulizia e la distribuzione nell'ambiente di staging, il file DLL è stato sostituito nel percorso di distribuzione dell'applicazione ASP.NET ( bin/ ). Questo non era il caso per l'ambiente di produzione.

Risulta in un ramo di test che ho aggiunto un passaggio al processo di compilazione per copiare questo file DLL nella directory bin . Ora la parte che ci è voluto un po 'per capire. Il processo CI non si puliva da solo. La DLL veniva lasciata nella directory di lavoro e veniva accidentalmente impacchettata con il file .zip di ASP.NET. Il ramo di produzione non ha mai copiato il file DLL nello stesso modo e non è mai stato distribuito accidentalmente.

TLDR; Controlla e assicurati di sapere cosa sta facendo il tuo server di build.




Il riferimento agli assembly che non vengono utilizzati durante la compilazione non è la pratica corretta. Si dovrebbe aumentare il file di build in modo che copi i file aggiuntivi. O utilizzando un evento post build o aggiornando il gruppo di proprietà.

Alcuni esempi possono essere trovati in altri post




Un altro scenario in cui appare è se si sta utilizzando il tipo di progetto "Sito Web" più vecchio in Visual Studio. Per quel tipo di progetto, non è in grado di fare riferimento a file .dll che si trovano all'esterno della propria struttura di directory (cartella corrente e in basso). Quindi, nella risposta sopra, diciamo che la struttura della directory è simile alla seguente:

Dove ProjectX e ProjectY sono directory padre / figlio e riferimenti ProjectX A.dll che a loro volta fanno riferimento a B.dll e B.dll si trovano all'esterno della struttura di directory, ad esempio in un pacchetto Nuget nella radice (Pacchetti), quindi A. dll sarà incluso, ma B.dll no.




Ho avuto lo stesso problema e la DLL era un riferimento caricato in modo dinamico. Per risolvere il problema ho aggiunto un "utilizzo" con lo spazio dei nomi della DLL. Ora la dll viene copiata nella cartella di output.






Related