Non è stato ansible aggiungere un riferimento alla DLL

Quando aggiungo un file .dll come riferimento nell’applicazione C # mostra un errore:

Non è stato ansible aggiungere un riferimento alla “…. dll”. Assicurarsi che il file sia accessibile e che sia un assembly valido o un componente COM.

ILDissassembler dice che non c’è un header CLR valido, quindi cerco di registrarlo usando regsvr32 e questo mi dà un altro errore:

Il modulo “” è stato caricato ma la chiamata a DLLRegisterServer non è riuscita con il codice di errore “0x80004005”

Sto usando la versione definitiva di VS2010 su una macchina Windows 7 a 64 bit. Quale potrebbe essere il problema?

Grazie per eventuali suggerimenti / risposte

Quanto segue ha funzionato per me:

Risposta breve

Esegui il seguente tramite la riga di comando (cmd):

TlbImp.exe cvextern.dll //where cvextern.dll is your dll you want to fix. 

E una dll valida verrà creata per te.

Risposta più lunga

  • Apri cmd

  • Trova TlbImp.exe. Probabilmente si trova in C: \ Programmi (x86) \ Microsoft SDK \ Windows \ v7.0A \ Bin. Se non riesci a trovarlo vai nella cartella principale (C: \ o D 🙂 ed esegui:

     dir tlbimp.exe /s //this will locate the file. 
  • Esegui tlbimp.exe e rimuovi la tua DLL. Esempio: se la tua DLL è cvextern.dll. Puoi eseguire:

     TlbImp.exe cvextern.dll 
  • Una nuova DLL è stata creata nella stessa cartella di tlbimp.exe. Puoi usarlo come riferimento nel tuo progetto.

È ansible aggiungere una DLL (o EXE) a un progetto solo se si tratta di un assembly .NET. Se non lo è, vedrai questo messaggio di errore.

regsvr32 fa anche alcune ipotesi sulla struttura e sulla funzione esportata nella DLL. È passato un po ‘di tempo da quando l’ho usato, ma ha a che fare con la registrazione dei server COM, quindi alcuni punti di ingresso devono essere disponibili. Se regsvr32 non riesce, la DLL non fornisce quei punti di ingresso e la DLL non contiene un componente COM.

L’unica possibilità per l’utilizzo della DLL è di importarla come qualsiasi altro binario non- .NET, ad esempio quando si utilizzano determinate API Win32. C’è un vecchio articolo di MSDN Magazine che potrebbe essere utile. Vedere il seguente aggiornamento per informazioni su dove ottenere l’articolo.

Aggiornamento 12 marzo 2018: il collegamento a MSDN Magazine non funziona più come in passato ad agosto 2010. L’articolo di Jason Clark si intitola “.NET Column: Calling DLL Win32 in C # con P / Invoke”. È stato pubblicato nel numero di luglio 2010 di MSDN Magazine. La “Wayback Machine” ha l’articolo qui al momento (la formattazione è limitata). L’intero numero MSDN Magazine di luglio 2010 è disponibile qui (solo formato HCM, istruzioni su come utilizzare i file HCM qui ).

Ho usato Dipendenza Walker per controllare i riferimenti interni che la DLL stava avendo. Si scopre che aveva bisogno del runtime VB msvbvm60.dll e dal momento che la mia casella di sviluppo non ha installato non sono stato in grado di registrarlo utilizzando regsvr32

Questa sembra essere la risposta alla mia domanda iniziale per ora.

Assicurati che il tuo compilatore sia impostato su x86 se stai provando a fare riferimento a una x86 dll …

Stavo avendo problemi simili … come detto sopra, cercando di usare OLEDB per accedere a un file Excel dal mio codice C # in Visual Studio 2012.

Continuavo a ricevere errori sulla libreria Access non accessibile, ma sapevo di averlo caricato.

Durante Debug, mi sono reso conto che sto compilando per 64 bit ma ho caricato Office x86. Anche se ho caricato la libreria Access per 32 bit, non è mai stata utilizzata dall’app … e quindi non era accessibile.

Ecco cosa stavo usando in C #:

“Provider = Microsoft.ACE.OLEDB.12.0; Data Source =” + strFilePath + “; Proprietà estesa = ‘Excel 12.0 Xml; HDR = Sì'”;

… Stavo ricevendo un errore

Non appena ho cambiato il compilatore in x86 ha funzionato

Mi sono appena imbattuto in questo problema e, dopo tutte le spiegazioni sulla correzione con il prompt dei comandi, ho scoperto che se lo aggiungi direttamente al progetto puoi semplicemente includere la libreria su ogni pagina che è necessaria

Ho lo stesso problema con l’importazione di WinSCard.dll nel mio progetto. Mi occupo di quella importazione direttamente da dll in questo modo:

 [DllImport("winscard.dll")] public static extern int SCardEstablishContext(int dwScope, int pvReserved1, int pvReserved2, ref int phContext); [DllImport("winscard.dll")] public static extern int SCardReleaseContext(int phContext); 

È ansible aggiungere questo per separare il progetto e quindi aggiungere un riferimento dal progetto principale.

Non è ansible aggiungere un riferimento a una DLL nativa . Tuttavia è ansible includerli nella soluzione (soluzione con il tasto destro del mouse, selezionare “Aggiungi file esistente”), ma non verranno referenziati a meno che non si dichiari qualcosa come

 [DllImport("...")] public static extern void MyFunction(); 

Forse c’è una specie di DLL wrapper , che stai effettivamente facendo riferimento e che contiene le importazioni DLL.

A volte, puoi fare riferimento alla DLL wrapper ma non riesci ancora a far funzionare il tuo programma, dove la richiesta di errore ti suggerisce di assicurarti che il file esista e che tutte le dipendenze siano disponibili.

Questo problema è dovuto al fatto che l’assembly che si sta tentando di aggiungere è mirato e compilato solo per un’architettura di processore x86 o x64 .

Prova a cambiare la piattaforma di destinazione su x86 o x64 in Build -> Configuration Manager .

Ho affrontato un problema simile. Stavo cercando di aggiungere il riferimento di una DLL .net 2.0 a un progetto .Net 1.1. Quando ho provato ad aggiungere una versione precedente del file .dll che era conforms a .Net 1.1. ha funzionato per me

Per chiunque altro cerchi aiuto su questo argomento, o sperimentando una FileNotFoundException o una FirstChanceException, controlla la mia risposta qui:

Si è verificata una prima eccezione di tipo “System.IO.FileNotFoundException” in mscorlib.ni.dll – windows phone

In generale, devi essere assolutamente certo di soddisfare tutti i requisiti per fare il riferimento – so che è la risposta ovvia, ma probabilmente stai trascurando un requisito relativamente semplice.

Ho avuto questo problema dopo che il mio PC è stato riavviato durante la creazione della soluzione. I miei due riferimenti sono andati, quindi ho dovuto ribuild manualmente i miei due progetti e quindi ho potuto aggiungere riferimenti senza errori.

Ho avuto questo errore durante la scrittura di un servizio di Windows. Stavo eseguendo Visual Studio come amministratore in modo che i miei comandi post build installassero automaticamente il mio servizio. Ho notato che quando chiudevo tutto e facevo funzionare normalmente VS (non come amministratore), permettevo di aggiungere i riferimenti senza errori.

Spero che questa soluzione funzioni per te.

Normalmente in Visual Studio 2015 è necessario creare il progetto dll come progetto C ++ -> CLR dai modelli di Visual Studio, ma tecnicamente è ansible abilitarlo dopo il fatto:

La proprietà critica è denominata Common Language Runtime Support impostato nella configurazione del progetto. Si trova in Configuration Properties > General > Common Language Runtime Support .

Quando si esegue questa operazione, VS probabilmente non aggiornerà l’opzione ‘Target .NET Framework’ (come dovrebbe). È ansible aggiungere manualmente questo scaricando il progetto, modificando il file your_project.xxproj e aggiungendo / aggiornando il tag XML Target .NET framework Version XML di Target .NET framework Version .

Per un esempio, suggerisco di creare una nuova soluzione come progetto CLR C ++ e di esaminare l’XML lì, magari anche di diffonderla per assicurarmi che non ci sia nulla di molto importante che sia fuori dall’ordinario.

Avevo bisogno di cambiare l’architettura in x86 da x64 nel configuration manager e copiare la mia dll a 32 bit (linguaggio C – pcProxAPI.dll) nella nuova cartella creata .. Questo è in cima ai passi descritti da “Sashus” di seguito .

C: \ Projects .. \ bin \ x86 \ Debug

La mia risposta è un po ‘in ritardo, ma come test rapido, assicurati di utilizzare l’ultima versione di librerie.

Nel mio caso, dopo aver aggiornato una libreria di nuget che faceva riferimento a un’altra libreria che causava il problema, il problema era scomparso.

Ho avuto lo stesso problema quando ho provato ad aggiungere una DLL che ho appena codificato. Ho scoperto che avevo bisogno di impostare le proprietà del progetto da cui proviene la mia DLL:

  • Configuration Properties\General\Common Language Runtime Support: /clr
  • Configuration Properties\C/C++\General\Common Language RunTime Support: /clr

Perché il progetto in cui volevo usare questa dll era anch’esso impostato in quel modo (aveva le stesse proprietà impostate su /clr ).