Impossibile utilizzare il controllo Winforms a causa di dipendenze non risolte

Question

Problema: ho un controllo WinForms ('MyControl') con una dipendenza su myCli.dll, una dll scritta in C++ CLI. Questo componente è di terze parti (scritto da un'altra squadra). myCli.dll ha una dipendenza da myLibrary.dll che è stata scritta da un'altra parte. Il controllo è presente in myAssembly.dll, che è una libreria di controlli e risorse C#.

Ho avuto questo controllo ottimo quando myCli.dll non aveva una dipendenza su myLibrary.dll. Potrei aggiungerlo alle forme, costruirlo e così via. Ma la nuova versione di myCli.dll è uscita e ho ricollegato a questo. Improvvisamente, l'IDE si sta comportando male. Il problema chiave sembra essere che l'IDE non è in grado di risolvere la dipendenza myCli.dll su myLibrary.dll.

Quando si tenta di trascinare il controllo dalla casella degli strumenti in un'area di progettazione, ottengo l'errore:

"Failed to create component 'MyControl'. 

Il messaggio di errore segue:

'System.IO.FileNotFoundException: Could not load file or assembly 'myCli.dll, Version 0.0.0.0, Culture=neutral, PublicKeyToken=2fb8da784abc560a' or one of its dependencies. 
The system cannot find the file specified" 

La mia convinzione è che se posso capire dove mettere myLibrary.dll, risolverò il problema di riferimento. Non lo so per certo. Qualcuno sa cosa dovrei fare per risolvere il problema?

Answer 1

Penso che la DLL deve entrare nella directory del progetto, quindi impostarla per essere copiata nella directory di output su build.

Answer 2

Per il supporto di design, penso che il myLibrary.dll deve neanche andare in C:\Program Files\Visual Studio xxx\Common7\IDE\PublicAssemblies (assumendo che myCLI.dll vive anche lì), o al luogo in cui myCLI.dll esiste oppure si potrebbe provare a copiare alla C:\Windows\System32 - il sistema dovrebbe essere in grado di trovarlo poi.

Assicurarsi di aggiungerlo al progetto e impostarlo su "Copia sempre" come suggerito da Clippit '98.

Answer 3

Un altro modo per trovare il posto giusto potrebbe essere l'utilizzo di Process Monitor. Basta filtrare l'output per la tua DLL e controllare in quali percorsi cerca il file.

Answer 4

myCli.dll e tutte le sue dipendenze devono essere nella stessa cartella esatta, altrimenti VS non sarà in grado di trovarli.

Il modo più semplice per eseguire questa operazione è assicurarsi che quando si crea myCli.dll, copi tutti i file nelle cartelle Debug/Release e quindi faccia riferimento a quei controlli nel progetto dalle cartelle Debug/Release. direttamente.

Answer 5

Nel mio caso il mio codice su Initialize e Form_Load conteneva le chiamate a un altro progetto in base ai riferimenti DLL. Escludendo questo codice con

if (!DesignMode) 
{ 
    //add your initializing code (for runtime!) here 
} 

ero in grado di aggiungere il controllo sulla fase di progettazione.

HTH

Answer 6

So che questo è un vecchio thread, ma solo rintocchi con quello che ho usato per risolvere il mio problema esatto.

Inizialmente ho utilizzato la soluzione di Peter Rakké da questa domanda (https://stackoverflow.com/a/15077337/34440). Ma non era l'ideale in quanto ha forzato un cambiamento nei miei schemi abituali.

Poiché il mio C++/CLI utilizzava solo funzioni dalla dll nativa al momento dell'esecuzione e conteneva le proprie informazioni di interfaccia, ho appena cambiato le DLL native da caricare in ritardo. Ho aggiunto le due DLL native sotto le impostazioni del progetto in Visual Studio (Proprietà progetto -> Proprietà di configurazione -> Linker -> Input -> Delay Loaded Dlls). Assicurarsi di impostare i menu a discesa Configurazione e piattaforma nella parte superiore della finestra di dialogo delle proprietà come opzioni Tutte e completare una ricostruzione.

Potrei quindi fare riferimento ai tipi dalla DLL C++/CLI nei miei controlli e moduli annidati.

Answer 7

Stessa situazione di MedicineMan. Progetto WinForms utilizzando 2 diversi componenti in libraryA.dll, che a sua volta aveva una dipendenza da libraryB.dll.

soluzione che ha funzionato per me (solo riferimento DLL applicabili in tutti i progetti, anche quando tutte le librerie sono costruite in modalità debug, e senza copiare manualmente le DLL in cartelle diverse):

1. Per i componenti in libraryA. DLL che Override disegnare eventi, uscita se in modalità DesignTime:

   If Me.DesignMode Then Exit Sub 
   

2. per i componenti in libraryA.dll con proprietà pubbliche utilizzando i tipi da libraryB.dll, utilizzare gli attributi per nascondere questi oggetti di designer (controllare attentamente la sintassi - Ho visto diversi altri post che hanno alcune strane ortografia/variazioni):

   <DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> 
   

3. componenti ricostruire, poi ri-avviare Visual Studio prima di utilizzare nel progetto WinForms. Per qualche motivo le modifiche agli attributi non vengono rilevate durante la stessa sessione e ho bruciato un altro paio di ore prima di provare l'ovvio.

Se hai ancora dei problemi, c'è un ottimo post su come ottenere informazioni di debug durante la componente vincolante (cioè quando si trascina-n-drop componente sullo modulo): How to enable assembly bind failure logging (Fusion) in .NET (scorrere verso il basso per rispondere da Mike Goatly) .

Buona fortuna.