La DLL dipendente non viene copiata nella cartella di output della generazione in Visual Studio

Ho una soluzione di Visual Studio. Ho molti progetti nella soluzione. C'è un progetto principale che funge da start up e utilizza altri progetti. C'è un progetto che dice "ProjectX". Il suo riferimento viene aggiunto al progetto principale. ProjectX fa riferimento a un'altra DLL .NET (ad esempio abc.dll) che non fa parte della soluzione.

Ora questo abc.dll dovrebbe essere copiato nella cartella bin / debug del progetto principale, ma non viene copiato lì. Perché non viene copiato, qualche motivo noto?

Ho scoperto che se ProjectX fa riferimento ad abc.dll ma non utilizza direttamente nessuno dei tipi DEFINED in abc.dll, abc.dll NON verrebbe copiato nella cartella di output principale. (Sarebbe copiato nella cartella di output di ProjectX, per renderlo più confuso.)

Quindi, se non stai usando esplicitamente nessuno dei tipi di abc.dll in nessun punto di ProjectX, metti una dichiarazione fittizia da qualche parte in uno dei file in ProjectX.

AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied

Non è necessario eseguire questa operazione per ogni classe: una sola volta sarà sufficiente per far copiare la DLL e tutto funzionerà come previsto.

Addendum: si noti che potrebbe funzionare per la modalità debug, ma NON per il rilascio. Vedi la risposta di @nvirth per i dettagli.

Solo un sidenote alla risposta di Overlord Zurg.

Ho aggiunto il riferimento fittizio in questo modo e ha funzionato in modalità Debug:

public class DummyClass
{
    private static void Dummy()
    {
        var dummy = typeof(AbcDll.AnyClass);
    }
}

Ma in modalità Release, la DLL dipendente non è stata ancora copiata.
Questo ha funzionato comunque:

public class DummyClass
{
    private static void Dummy()
    {
        Action<Type> noop = _ => {};
        var dummy = typeof(AbcDll.AnyClass);
        noop(dummy);
    }
}

Questa informazione in realtà mi è costata ore per capire, quindi ho pensato di condividerla.

Sì, dovrai impostare Copy Localsu true. Tuttavia, sono abbastanza sicuro avrete anche bisogno di riferimento che il montaggio dal progetto principale e insieme Copy Locala truecosì - non solo ottenere copiato da un assembly dipendente.

È possibile accedere alla Copy Localproprietà facendo clic sull'assieme in Referencese premendo F4.

Sembra liscio quando lo rendi un attributo assembly

[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{        
    public ForceAssemblyReference(Type forcedType)
    {
        //not sure if these two lines are required since 
        //the type is passed to constructor as parameter, 
        //thus effectively being used
        Action<Type> noop = _ => { };
        noop(forcedType);
    }
}

L'utilizzo sarà:

[assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]

Ho affrontato questo stesso problema. Informazioni di base: prima della costruzione, avevo aggiunto un nuovo progetto X alla soluzione. Il progetto Y dipendeva dal progetto X e il progetto A, B, C dipendeva dal progetto Y.

Gli errori di compilazione sono stati che non è stato possibile trovare le DLL Progetto A, B, C, Y e X.

La causa principale era che il progetto X di nuova creazione era destinato a .NET 4.5, mentre il resto dei progetti di soluzione era destinato a .NET 4.5.1. Il progetto X non è stato creato impedendo la costruzione del resto dei progetti.

Assicurarsi che qualsiasi progetto appena aggiunto abbia come target la stessa versione .NET del resto della soluzione.

Non sono sicuro se questo aiuta, ma per me, molte volte faccio riferimento a una DLL (che ovviamente la aggiunge automaticamente alla cartella bin). Tuttavia, quella DLL potrebbe richiedere DLL aggiuntive (a seconda delle funzioni che sto usando). NON voglio fare riferimento a quelli nel mio progetto perché devono semplicemente finire nella stessa cartella della DLL che sto effettivamente utilizzando.

Realizzo questo in Visual Studio "aggiungendo un file esistente". Dovresti essere in grado di aggiungerlo ovunque tranne la cartella Add_data. personalmente l'ho appena aggiunto alla radice.

Quindi modificare le proprietà di quel file in ...

Build Action = None (se impostato su qualcosa come Content, in realtà copia la versione "root" nella radice, più una copia nel Cestino).

Copia nella cartella di output = Copia se più recente (in pratica lo inserisce nella cartella BIN solo se manca, ma non lo fa dopo)

Quando pubblico .. la mia DLL aggiunta esiste solo nella cartella BIN e in nessun altro luogo nella posizione Pubblica (che è quello che voglio).

Puoi anche verificare che le DLL che stai cercando non siano incluse nel GAC. Credo che Visual Studio sia intelligente nel non copiare quei file se esiste già nel GAC sulla macchina di compilazione.

Di recente mi sono imbattuto in questa situazione in cui avevo testato un pacchetto SSIS che aveva bisogno di assiemi nel GAC. Da allora l'avevo dimenticato e mi chiedevo perché quelle DLL non uscissero durante una build.

Per controllare cosa c'è nel GAC (da un prompt dei comandi per sviluppatori di Visual Studio):

gacutil -l

O l'output in un file per facilitare la lettura:

gacutil -l > output.txt
notepad.exe output.txt

Per rimuovere un assieme:

gacutil -u MyProjectAssemblyName

Dovrei anche notare che una volta rimossi i file dal GAC, sono stati correttamente emessi nella directory \ bin dopo una compilazione (anche per gli assembly a cui non era stato fatto direttamente riferimento nel progetto root). Questo era su Visual Studio 2013 Update 5.

Nel mio caso, è stata la cosa più stupida, causata da un comportamento predefinito di TFS / VS con cui non sono d'accordo.

Poiché l'aggiunta della dll come riferimento al progetto principale non ha funzionato, ho deciso di aggiungerla come "elemento esistente", con Copia locale = Sempre. Anche allora il file non c'era.

Si scopre che, anche se il file è presente sulla soluzione VS e tutto compilato sia localmente che sul server, VS / TFS non ha aggiunto effettivamente il file al controllo del codice sorgente. Non è stato incluso nei "Modifiche in sospeso". Ho dovuto andare manualmente a Explorer controllo sorgente e fare esplicito clic sull'icona "Aggiungi elementi alla cartella".

Stupido perché ho sviluppato per 15 anni in VS. Mi sono già imbattuto in questo, non me lo ricordavo e in qualche modo mi mancava perché tutto era ancora compilato perché il file era un riferimento regolare, ma il file aggiunto come elemento esistente non veniva copiato perché non esisteva su il server di controllo del codice sorgente.

Spero che questo salvi qualcuno un po 'di tempo, dal momento che ho perso 2 giorni della mia vita per questo.

Questa è una leggera modifica dell'esempio di nvirth

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}

Lo aggiungerei agli eventi di Postbuild per copiare le librerie necessarie nelle directory di output. Qualcosa come XCopy pathtolibraries targetdirectory

Puoi trovarli nelle proprietà del progetto -> Crea eventi.

Problema:

Si è verificato un problema simile per una DLL del pacchetto NuGet (Newtonsoft.json.dll) in cui l'output di generazione non include la DLL di riferimento. Ma la compilation va bene.

fix:

Esamina i tuoi progetti in un editor di testo e cerca riferimenti con tag in essi contenuti. Come vero o falso. "Privato" è sinonimo di "Copia locale". Da qualche parte nelle azioni, MSBuild sta prendendo per individuare le dipendenze, sta trovando la tua dipendenza da qualche altra parte e sta decidendo di non copiarla.

Quindi, esamina ogni file .csproj / .vbproj e rimuovi i tag manualmente. Ricostruisci e tutto funziona in Visual Studio e MSBuild. Una volta che hai funzionato, puoi tornare indietro e aggiornare il dove pensi che debbano essere.

Riferimento:

https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/

NESSUN BISOGNO DEL MANICHINO IN CODICE
Solo:

aggiungere un riferimento al progetto eseguibile

o / e assicurarsi che il riferimento nel progetto eseguibile sia "Copy Local"impostato su TRUE(che era il mio " errore ") sembra che questo "sovrascritto" l'impostazione nel progetto libreria di riferimento di base ...

Se fai clic con il pulsante destro del mouse sull'assieme di riferimento, vedrai una proprietà chiamata Copia locale . Se Copia locale è impostato su true, l'assembly deve essere incluso nel cestino. Tuttavia , sembra che ci sia un problema con Visual Studio, che a volte non include la dll di riferimento nella cartella bin ... questa è la soluzione che ha funzionato per me:

TLDR; Visual Studio 2019 potrebbe richiedere semplicemente un riavvio.

Ho riscontrato questa situazione utilizzando progetti basati sul progetto Microsoft.NET.Sdk.

<Project Sdk="Microsoft.NET.Sdk">

In particolare:

• Project1: obiettivi .netstandard2.1
  • riferimenti Microsoft.Extensions.Logging.Consolevia Nuget
• Project2: obiettivi .netstandard2.1
  • riferimenti Project1tramite un riferimento al progetto
• Project2Tests: obiettivi .netcoreapp3.1
  • riferimenti Project2tramite un riferimento al progetto

Durante l'esecuzione del test, ho ricevuto il messaggio di errore che indicava che Microsoft.Extensions.Logging.Consolenon è stato possibile trovare e che in effetti non si trovava nella directory di output.

Ho deciso di aggirare il problema aggiungendo Microsoft.Extensions.Logging.Consolea Project2, solo per scoprire che Nuget Manager di Visual Studio non era elencato Microsoft.Extensions.Logging.Consolecome installato Project1, nonostante sia presente nel Project1.csprojfile.

Un semplice arresto e riavvio di Visual Studio hanno risolto il problema senza la necessità di aggiungere un riferimento aggiuntivo. Forse questo farà risparmiare a qualcuno 45 minuti di perdita di produttività :-)

È possibile impostare sia il progetto principale che il percorso di output della build di ProjectX sulla stessa cartella, quindi è possibile ottenere tutte le DLL necessarie in quella cartella.

Assicurarsi che la DLL dipendente utilizzata dall'utente non abbia un framework .net di destinazione superiore al framework .net di destinazione dell'applicazione del progetto.

Puoi verificarlo selezionando il tuo progetto, quindi premi ALT + INVIO, quindi seleziona Applicazione dal lato sinistro e quindi seleziona Target Framework del tuo progetto.

Supponiamo, dll Target Framework = 4.0 dipendente e Application dll Target Framework = 3.5, quindi cambialo in 4.0

Grazie!

Oltre a quelli comuni sopra, avevo una soluzione multi-progetto da pubblicare. Apparentemente alcuni file hanno come target diversi framework.

Quindi la mia soluzione: Proprietà> Versione specifica (Falso)

Aggiungi la DLL come elemento esistente a uno dei progetti e dovrebbe essere ordinata

VS2019 V16.6.3

Per me il problema era in qualche modo il file .proj principale finito con una voce come questa per il progetto la cui DLL non veniva copiata nella cartella bin del progetto principale:

<ProjectReference Include="Project B.csproj">
  <Project>{blah blah}</Project>
  <Name>Project B</Name>
  <Private>True</Private>
</ProjectReference>

Ho eliminato manualmente la riga <Private>True</Private>e la DLL è stata quindi copiata nella cartella principale del progetto su ogni build del progetto principale.

Se vai al riferimento del progetto problema nella cartella riferimenti del progetto principale, fai clic su di esso e visualizza le proprietà c'è un'impostazione "Copia locale". Il tag privato equivale a questa impostazione, ma per me per qualche motivo la modifica della copia locale non ha avuto alcun effetto sul tag privato nel file .proj.

In modo fastidioso non ho cambiato il valore locale della copia per il riferimento, non ho idea di come sia stato impostato in quel modo e un altro giorno ho sprecato a rintracciare uno stupido problema con VS.

Grazie a tutte le altre risposte che mi hanno aiutato a individuare la causa.

HTH