Designer che rifiuta il controllo utente

Question

Ho un progetto di libreria di controllo C++ compilato utilizzando/CLR. All'interno di questo progetto c'è un controllo utente che effettua una chiamata a una DLL nativa. Questo controllo utente appare nella casella degli strumenti del designer come dovrebbe, ma non posso quindi trascinarlo su un modulo. Senza il riferimento alla DLL, il controllo utente può essere utilizzato correttamente, ma con il riferimento viene visualizzato solo il messaggio "Impossibile caricare la casella degli strumenti" quando si tenta di utilizzarlo.

La chiamata nativa è funzionale e non danneggia in alcun modo il controllo utente. Il controllo utente può essere visto bene nella finestra di progettazione da solo con la chiamata DLL inclusa. Inoltre, se il controllo viene aggiunto manualmente a un modulo ed eseguito come programma, verrà visualizzato correttamente.

Questo mi fa sospettare che il problema sia solo una questione di Visual Studio Designer che ha bisogno di sapere dove si trova quella DLL nativa. Ma non sono sicuro di come dirlo, o dove mettere la DLL in modo che possa trovarlo. Per quanto ne so, non c'è modo nelle impostazioni del progetto di fare riferimento a una DLL nativa. Quindi ha senso per me che il designer si stia solo lamentando perché non può farlo.

C'è un modo per farlo funzionare?

Answer 1

Sfortunatamente, si è verificato un "bug di progettazione" in VS (o in altre parole, una "funzione").

Il tuo sospetto che il problema riguardi il progettista di Visual Studio che ha bisogno di sapere dove si trova la DLL nativa è parzialmente a destra. Non è una questione di ignoranza per la sua posizione, ma piuttosto il fatto che il progettista non può riflettere sugli assembly in modalità mista (quelli che contengono sia il codice gestito e nativo) al fine di istanziare il controllo. Ciò sta causando la casella degli strumenti per mostrare l'errore che hai notato.

La soluzione alternativa consiste nel compilare i file di origine C++ utilizzando /clr:pure per creare un file EXE gestito in modo semplice.

Un'altra possibilità (anche un "bug di progettazione" in VS) è che il controllo che si sta tentando di aggiungere è stato compilato come componente a 64 bit. Poiché Visual Studio è un processo a 32 bit, può solo eseguire moduli a 32 bit. Mentre consente di aggiungere un riferimento a un assembly a 64 bit, in realtà non può JIT compilare quell'assembly a 64 bit ed eseguirlo all'interno del processo.

La soluzione qui è quella di compilare il gruppo di controllo utente utilizzando l'impostazione "AnyCPU", che verrà eseguita come processo a 32 bit in un ambiente a 32 bit e un processo a 64 bit in un 64- ambiente bit. Davvero, questo è il meglio di entrambi i mondi, assumendo che tu abbia scritto il tuo codice correttamente.

Infine, se nessuno di quelli di lavoro, c'è sempre la possibilità di bypassare il progettista.È ancora possibile scrivere il codice necessario per creare un'istanza del controllo utente e impostarne le proprietà nell'inizializzatore del modulo. Tutto ciò che si perde è la possibilità di utilizzare il controllo all'interno del designer all'interno di Visual Studio. Tutto funzionerebbe come previsto in fase di esecuzione.

Answer 2

Cose da provare:

VS2010: copiare la dll nella cartella Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies.

VS2008, VS2010: copiare la DLL nella cartella AppData\Local\Microsoft\VisualStudio\<version>\ProjectAssemblies\.

Answer 3

Mi sembra che il controllo con il riferimento alla DLL nativa non riesca perché Visual Studio non può caricarlo. Prova a impostare la variabile d'ambiente PATH a livello globale o per l'eseguibile di Visual Studio quando lo esegui. Se ciò non aiuta, prova a eseguire il debug del comportamento del tempo di progettazione del tuo controllo e dovresti riuscire a individuare il problema.

Answer 4

Ho trovato questo che sembra un problema simile?

https://connect.microsoft.com/VisualStudio/feedback/details/388107/winforms-designer-fails-to-load-managed-dll-having-unmanaged-dependencies#details

Così MS sembra essere ufficialmente dire upgrade da VS2008 a VS2010 come una soluzione.

Hai mai trovato una soluzione alternativa?

Questo è un problema che sto riscontrando proprio in VS2008 con un progetto gestito C# .net che utilizza un progetto di wrapper C++ gestito che utilizza un progetto C++ non gestito.

Certamente mi sembra che gli assembly temporanei del designer utilizzati da Visual Studio siano un problema: carica l'assembly wrapper delle dipendenze rilevato nella cartella temporanea ma non le dipendenze non gestite di tale wrapper. Posso vedere questo è in C: \ Users \ Username \ AppData \ Local \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies. Quando provo a caricare il designer, viene creata una nuova cartella con la DLL gestita al suo interno ma non le dipendenze non gestite. Sfortunatamente non riesco a capire cosa sta dicendo la persona nella domanda dal link Microsoft sopra è la soluzione alternativa utilizzando $ (TargetDir).

Answer 5

Collega la libreria con l'opzione /DELAYLOAD:"your_native.dll ". Questo ha risolto lo stesso problema per me.

Answer 6

Ho avuto un problema simile a quello che potrebbe essere il tuo (chissà quante cose potrebbero causarlo?), In pratica non potevo rilasciare i controlli a un designer, ma i controlli esistenti funzionavano bene sia nella produzione che nei test.

Per la cronaca, qui era la mia soluzione:

1) modificare le impostazioni di soluzioni per x86. Questo mi ha permesso di mettere il controllo sul designer, spostarlo, ecc. 2) Al termine, è possibile tornare a AnyCPU o x64. In realtà sto solo usando il designer per semplificare l'impostazione di alcuni valori, e sembra che l'intera cosa a 32/64 bit causi problemi.