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




found aggiungere (15)

Se non si utilizza l'assembly direttamente nel codice, Visual Studio durante il tentativo di essere utile rileva che non viene utilizzato e non lo include nell'output. Non sono sicuro del motivo per cui stai riscontrando un comportamento diverso tra Visual Studio e MSBuild. Si potrebbe provare a impostare l'output di generazione su diagnostico per entrambi e confrontare i risultati per vedere dove si separa.

Per quanto riguarda il riferimento a elmah.dll se non lo si fa direttamente nel codice, è possibile aggiungerlo come elemento al progetto e impostare l'azione di Content su Content e la directory Copia su output su Always .

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!)


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


Ho appena avuto lo stesso identico problema e si è rivelato causato dal fatto che 2 progetti nella stessa soluzione facevano riferimento a una versione diversa della libreria di terze parti.

Una volta corretto tutti i riferimenti, tutto ha funzionato perfettamente.


Usando lo schema di deadlydog,

Y => X => A => B ,

il mio problema era quando ho costruito Y, gli assiemi (A e B, tutti e 15 di loro) di X non venivano visualizzati nella cartella bin di Y.

L'ho risolto rimuovendo la X di riferimento da Y, salvando, compilando, quindi aggiungendo di nuovo X riferimento (riferimento di progetto), e salvando, compilando, e A e B hanno iniziato a essere visualizzati nella cartella bin di Y.


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.

Controlla se la versione del tuo progetto è la stessa della versione framework della DLL che hai messo in riferimento.

Nel mio caso, il mio cliente è stato compilato usando "Framework 4 Client" e la DLL era in "Framework 4".


Ciò richiede l'aggiunta di un file .targets al progetto e la sua impostazione da includere nella sezione include del progetto.

Vedi la mia risposta qui per la procedura.


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.


Ho appena avuto un problema molto simile. Durante la compilazione con Visual Studio 2010, il file DLL è stato incluso nella cartella bin . Ma durante la compilazione con MSBuild il file DLL di terze parti non è stato incluso.

Molto frustrante. Il modo in cui ho risolto era includere il riferimento NuGet al pacchetto nel mio progetto web, anche se non lo sto usando direttamente lì.


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!)


Non sono sicuro del motivo per cui è diverso quando creo tra Visual Studio e MsBuild, ma ecco cosa ho trovato quando ho riscontrato questo problema in MsBuild e Visual Studio.

Spiegazione

Per uno scenario di esempio, diciamo che abbiamo il progetto X, l'assembly A e l'assembly B. Assembly Un assembly di riferimenti B, quindi il progetto X include un riferimento ad entrambi A e B. Inoltre, il progetto X include il codice che fa riferimento all'assembly A (ad es. A. SomeFunction ()). Ora crei un nuovo progetto Y che fa riferimento al progetto X.

Quindi la catena delle dipendenze ha questo aspetto: Y => X => A => B

Visual Studio / MSBuild cerca di essere intelligente e porta i riferimenti solo nel progetto Y che rileva come richiesto dal progetto X; lo fa per evitare l'inquinamento di riferimento nel progetto Y. Il problema è che, poiché il progetto X in realtà non contiene alcun codice che utilizza esplicitamente l'assembly B (ad esempio B.SomeFunction ()), VS / MSBuild non rileva che B è richiesto da X, e quindi non lo copia nella directory bin del progetto Y; copia solo gli assi X e A.

Soluzione

Sono disponibili due opzioni per risolvere questo problema, che comporteranno l'assemblaggio B copiato nella directory bin del progetto Y:

  1. Aggiungere un riferimento all'assieme B nel progetto Y.
  2. Aggiungi codice fittizio a un file nel progetto X che utilizza l'assembly B.

Personalmente preferisco l'opzione 2 per un paio di motivi.

  1. Se in futuro aggiungi un altro progetto che fa riferimento al progetto X, non dovrai ricordarti di includere anche un riferimento all'assembly B (come avresti dovuto fare con l'opzione 1).
  2. Puoi avere commenti espliciti che spiegano perché il codice fittizio deve essere presente e non rimuoverlo. Quindi, se qualcuno elimina il codice per errore (ad esempio con uno strumento refactor che cerca codice inutilizzato), è possibile vedere facilmente dal codice sorgente che il codice è richiesto e ripristinarlo. Se si utilizza l'opzione 1 e qualcuno utilizza uno strumento refactor per ripulire i riferimenti non utilizzati, non si hanno commenti; vedrai semplicemente che è stato rimosso un riferimento dal file .csproj.

Ecco un esempio del "codice fittizio" che in genere aggiungo quando incontro questa situazione.

    // DO NOT DELETE THIS CODE UNLESS WE NO LONGER REQUIRE ASSEMBLY A!!!
    private void DummyFunctionToMakeSureReferencesGetCopiedProperly_DO_NOT_DELETE_THIS_CODE()
    {
        // Assembly A is used by this file, and that assembly depends on assembly B,
        // but this project does not have any code that explicitly references assembly B. Therefore, when another project references
        // this project, this project's assembly and the assembly A get copied to the project's bin directory, but not
        // assembly B. So in order to get the required assembly B copied over, we add some dummy code here (that never
        // gets called) that references assembly B; this will flag VS/MSBuild to copy the required assembly B over as well.
        var dummyType = typeof(B.SomeClass);
        Console.WriteLine(dummyType.FullName);
    }

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.


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.


Come indicato nel numero 6583 della CLI dotnet, il problema dovrebbe essere risolto con dotnet nuget locals --clear all comando.







visual-studio msbuild reference dependencies project