Imansible trovare il file dei metadati “.dll”

Sto lavorando a un progetto WPF, C # 3.0, e ottengo questo errore:

Error 1 Metadata file 'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug \BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools \VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem 

Questo è il modo in cui faccio riferimento ai miei usercontrols:

 xmlns:vms="clr-namespace:VersionManagementSystem"  

Succede dopo ogni build fallita. L’unico modo per ottenere la soluzione da compilare è di commentare tutti i miei controlli utente e ribuild il progetto, quindi annullo i comandi utente e tutto va bene.

Ho controllato la configurazione degli ordini e delle dipendenze.

Come puoi vedere, sembra che abbia troncato il percorso assoluto del file DLL … Ho letto che c’è un bug con la lunghezza. È un problema ansible?

È molto fastidioso e dover commentare, compilare e decommentare, la build sta diventando estremamente noiosa.

Ho appena avuto lo stesso problema. Visual Studio non sta creando il progetto a cui si fa riferimento.

  1. Fare clic con il tasto destro del mouse sulla soluzione e fare clic su Proprietà.
  2. Fai clic su Configurazione a sinistra.
  3. Assicurati che la casella di controllo sotto “Crea” per il progetto che non riesce a trovare sia selezionata. Se è già selezionato, deseleziona, premi applica e seleziona di nuovo le caselle.

Questo può ancora accadere nelle versioni più recenti di Visual Studio (l’ho appena avuto in Visual Studio 2013):

Un’altra cosa da provare è chiudere Visual Studio ed eliminare il file .suo che si trova accanto al file .sln . (Verrà rigenerato la prossima volta che si Save all (o si esce da Visual Studio)).

Ho avuto questo problema quando ho aggiunto nuovi progetti alla soluzione su un’altra macchina e poi ho tirato le revisioni, ma il file .suo può essere corrotto anche in altri casi e portare a comportamenti di Visual Studio molto strani, quindi eliminarlo è uno delle cose che cerco sempre.

Si noti che l’eliminazione del file .suo reimposta i progetti di avvio della soluzione.

Maggiori informazioni sul file .suo sono qui .

La risposta suggerita non ha funzionato per me. L’errore è un’esca per un altro problema.

Ho scoperto che stavo prendendo di mira una versione leggermente diversa di .NET e questo è stato contrassegnato come un avvertimento dal compilatore, ma stava causando il fallimento dell’edificio. Questo dovrebbe essere stato contrassegnato come un errore e non come un avvertimento.

Bene, la mia risposta non è solo il riassunto di tutte le soluzioni, ma offre di più.

Sezione 1):

In soluzioni generali:

Ho avuto quattro errori di questo tipo (“imansible trovare il file dei metadati”) insieme a un errore che diceva “Imansible aprire il file di origine (‘Errore non specificato’) ‘.

Ho cercato di sbarazzarmi dell’errore ‘file metadata non trovato’. Per questo, ho letto molti post, blog, ecc. E ho trovato che queste soluzioni possono essere efficaci (riassumendole qui):

  1. Riavvia Visual Studio e prova a ribuild.

  2. Vai a ‘Esplora soluzioni’ . Fare clic destro su Soluzione. Vai a Proprietà . Vai a “Configuration Manager” . Controlla se le caselle di controllo sotto “Crea” sono spuntate o meno. Se alcuni o tutti sono deselezionati, controllali e prova a build di nuovo.

  3. Se le soluzioni precedenti non funzionano, segui la sequenza menzionata nel precedente passaggio 2 e, anche se tutte le caselle sono selezionate, deselezionale, controlla di nuovo e prova a ribuild.

  4. Ordine di costruzione e dipendenze del progetto:

    Vai a ‘Esplora soluzioni’ . Fare clic destro su Soluzione. Vai a “Dipendenze del progetto …” . Verranno visualizzate due tabs: “Dipendenze” e “Ordine di compilazione” . Questo ordine di build è quello in cui la soluzione viene creata. Controlla le dipendenze del progetto e l’ordine di costruzione per verificare se qualche progetto (ad esempio ‘project1’) che dipende da altri (ad esempio ‘progetto2’) sta cercando di creare prima quello (progetto2). Questa potrebbe essere la causa dell’errore.

  5. Controlla il percorso della .dll mancante:

    Controlla il percorso della .dll mancante. Se il percorso contiene spazio o qualsiasi altro carattere di percorso non valido, rimuoverlo e riprovare a build.

    Se questa è la causa, regola l’ordine di costruzione.


Sezione 2):

Il mio caso particolare:

Ho provato tutti i passaggi precedenti con varie permutazioni e combinazioni con il riavvio di Visual Studio alcune volte. Ma non mi ha aiutato.

Così, ho deciso di sbarazzarmi di altri errori che stavo incontrando (‘Imansible aprire il file di origine (‘ Errore non specificato ‘)’).

Mi sono imbattuto in un post sul blog: Imansible aprire il file di origine TFS-Errore (‘Errore non specificato’)

Ho provato i passaggi indicati in quel post del blog e mi sono liberato dell’errore ‘Imansible aprire il file di origine (‘ Errore non specificato ‘) e sorprendentemente ho eliminato altri errori (‘ imansible trovare il file dei metadati ‘) come bene.


Sezione (3):

Morale della storia:

Prova tutte le soluzioni come menzionato nella sezione (1) sopra (e qualsiasi altra soluzione) per eliminare l’errore. Se non funziona nulla, come per il blog menzionato nella sezione (2) sopra, elimina le voci di tutti i file sorgente che non sono più presenti nel controllo sorgente e nel file system dal tuo file .csproj .

Nel mio caso è stato causato da una mancata corrispondenza della versione di .NET Framework.

Un progetto era 3.5 e l’altro progetto di referenziazione 4.6.1.

Chiudere e riaprire Visual Studio 2013 ha funzionato per me!

Beh, niente nelle risposte precedenti ha funzionato per me, quindi mi ha fatto pensare perché sto facendo clic e sperando che quando gli sviluppatori dovremmo davvero cercare di capire cosa sta succedendo qui.

Mi è sembrato ovvio che questo errato riferimento al file di meta-dati debba essere tenuto da qualche parte.

Una rapida ricerca del file .csproj mostrava le linee colpevoli. Avevo una sezione chiamata che sembrava aggrapparsi al vecchio percorso file errato.

   {5b0a347e-cd9a-4746-a3b6-99d6d010a6c2} Beeyp.Entities  ... 

Quindi una semplice soluzione davvero:

  1. Esegui il backup del tuo file .csproj.
  2. Trova i percorsi errati nel file .csproj e rinomina in modo appropriato.

Assicurati di eseguire il backup del tuo vecchio .csproj prima di giocherellare .

Ho ricevuto lo stesso errore “Imansible trovare il file dei metadati” .dll “, e ho provato diverse cose descritte in precedenza, ma il motivo dell’errore era che mi riferivo a un file DLL di terze parti che aveva come target una versione .NET più in alto che il mio progetto abbia come destinazione la versione .NET. Quindi la soluzione era cambiare il quadro di riferimento del mio progetto.

Ho anche incontrato questo problema. In primo luogo, devi creare manualmente un progetto DLL, facendo clic con il tasto destro del mouse su Build. Allora funzionerà.

Nel mio caso, ho la mia directory installata in modi errati.

Se il percorso della tua soluzione è qualcosa come “My Project% 2c Very Popular% 2c Unit Testing% 2c Software e Hardware.zip”, non può risolvere il file dei metadati, forse dovremmo evitare alcune parole non valide come% 2c.

Rinominare il percorso in nome normale ha risolto il problema.

Ho aggiunto un nuovo progetto alla mia soluzione e ho iniziato a ottenere questo.

La ragione? Il progetto che ho presentato riguardava un diverso framework .NET (4.6 e gli altri due erano 4.5.2).

Mi stavo strappando i capelli anche con questo problema, ma dopo aver provato le risposte precedenti, l’unica cosa che ha funzionato per me era aprire ogni progetto nella mia soluzione 1 per 1 e costruirli individualmente.

Quindi ho chiuso Visual Studio 2013, ho riaperto la mia soluzione e l’ho compilata correttamente.

È strano, perché se avessi fatto clic su ciascun progetto nel mio Solution Explorer e avessi provato a costruirli in quel modo, non ci sono riusciti. Ho dovuto aprirli da soli nelle loro soluzioni.

Per me è accaduto quando ho incluso un nuovo progetto in una soluzione.

Visual Studio seleziona automaticamente .NET Framework 4.5.

Ho cambiato la versione .NET 4.5.2 come le altre librerie e ha funzionato.

Per me, cercava di trovare una DLL in un percorso che conteneva il Progetto, ma lo avevamo spostato in una nuova directory. La soluzione aveva il percorso corretto per il progetto, ma in qualche modo Visual Studio continuava a cercare nella vecchia posizione.

Soluzione: rinominare ogni problema Progetto – basta aggiungere un carattere o qualsiasi altra cosa – quindi rinominarlo con il nome originale.

Questo deve resettare alcune cache globali di qualche tipo in Visual Studio, perché questo risolve sia questo problema sia molti altri, mentre cose come Clean no.

Per me i seguenti passaggi hanno funzionato:

  • Trova il progetto che non sta costruendo
  • Rimuovi / aggiungi riferimenti a progetti all’interno della soluzione.

La mia istanza del problema è stata causata da un progetto comune con un nome di class duplicato (con un nome file diverso). È strano che Visual Studio non sia stato in grado di rilevarlo e invece ha semplicemente fatto esplodere il processo di compilazione.

Ho riscontrato questo problema in Visual Studio 2012 in una soluzione con molti progetti. La ricostruzione manuale di ciascun progetto nella soluzione nello stesso ordine dell’ordine di creazione del progetto (clic con il pulsante destro del mouse e ricostruzione in Esplora soluzioni) è stata corretta per me.

Alla fine ho avuto uno che mi ha dato un errore di compilazione. Ho corretto l’errore e la soluzione si sarebbe sviluppata correttamente dopo.

Nel mio caso, il problema è stato causato da un semplice errore di compilazione,

errore CS0067: l’evento ‘XYZ’ non viene mai utilizzato

che, per qualsiasi motivo, non si è mostrato nella finestra di errore.

Per questo motivo, il sistema di sviluppo di Visual Studio sembrava mancare l’errore e ha cercato di creare progetti dipendenti, che a loro volta non funzionavano con il fastidioso messaggio dei metadati.

La raccomandazione è – per quanto stupida possa sembrare -:

Per prima cosa guarda la tua finestra di output !

Mi ci è voluta mezz’ora prima che questa idea mi colpisse …

Nel mio caso il problema era che avrei cancellato manualmente un file non di compilazione contrassegnato come “mancante”. Una volta cancellato il riferimento al file ora mancante e ricompilato – tutto andava bene.

Ho avuto lo stesso problema. Nel mio caso, il progetto sarebbe ancora costruito in modalità di rilascio ed è stato proprio quando ho provato a compilare debug che non è riuscito.

Quello che ho finito per risolvere il problema è stato semplicemente copiare tutte le DLL (e altri file dalla mia cartella di rilascio) nella mia cartella di debug. Dopo averlo fatto per ogni progetto, gli errori si sono sciolti.

Se si dispone di uno spazio nel nome della soluzione, anche questo causerà il problema. Rimuovendo lo spazio dal nome della soluzione, quindi il percorso non contiene% 20 lo risolverà.

Mettendo semplicemente in evidenza ciò che è palesemente ovvio: se non hai triggersto “Mostra finestra di output all’avvio di build”, assicurati di notare se la tua build non sta funzionando (piccolo errore “build failed” in basso a sinistra) !!!!

Ho avuto questo errore quando stavo cercando di pubblicare un’applicazione web. Si è scoperto che una delle proprietà di una class è stata inclusa

 #if DEBUG public int SomeProperty { get; set; } #endif 

ma l’uso della proprietà non lo era. La pubblicazione è stata effettuata nella configurazione Release senza il simbolo DEBUG , ovviamente.

Tornando a questo alcuni anni dopo, questo problema è più che probabile relativo al limite massimo di percorso di Windows:

Denominazione di file, percorsi e spazi dei nomi , Limitazione massima della lunghezza del percorso

Sto facendo funzionare Visual Studio 2013.

Sembra che le dipendenze di compilazione fossero errate. L’eliminazione dei file * .suo ha risolto i problemi che avevo.

Per il mio caso era che avevo commentato le classi in uno spazio dei nomi specifico (vuoto):

 namespace XYZW { // Class code } 

Quando ho rimosso il codice del namespace e i comandi di importazione (usando), ha risolto il problema.

Nella build stava anche dicendo – insieme al file DLL mancante del progetto:

errore CS0234: il tipo o il nome dello spazio dei nomi ‘W’ non esiste nello spazio dei nomi ‘XYZ’ (ti manca un riferimento all’assembly?)

Anch’io ho avuto lo stesso errore. Si nasconde come nel percorso sottostante. Il percorso cui ho fatto riferimento per il file DLL è come “D: \ Assemblies Folder \ Assembly1.dll”.

Ma il percorso originale in cui l’assembly si riferiva era “D: \ Assemblies% 20Folder \ Assembly1.dll”.

A causa di questa variazione del nome del percorso, l’assembly non può essere recuperato dal suo percorso originale e quindi genera l’errore “Metadata not found”.

La soluzione è nella domanda Stack Overflow Come faccio a sostituire tutti gli spazi con% 20 in C #? .

Questo errore può essere visualizzato se si utilizzano assiemi fasulli. La rimozione dei falsi porta alla creazione di successo del progetto.

Ho ricevuto questo errore dopo aver aperto un progetto in cui è stato fatto riferimento a Entity Framework, quindi ho eliminato tali riferimenti e reinstallato Entity Framework versione 6.0.0.0 tramite pthe acket manager in questo modo:

 install-package entityframework -version 6.0.0.0 

L’errore stava ancora mostrando, quindi ho pensato che quei riferimenti fossero lì perché c’era una versione più vecchia di Entity Framework presumibilmente “preinstallata” sul progetto, ma non funzionava davvero.

Così sono andato sul file packages.config e ho notato che c’era un altro riferimento:

  ****   

Poi ho cancellato la linea, pulito e ricostruito il progetto e la soluzione del contenitore, e alla fine ha funzionato.

Ho avuto un problema simile quando ho decompilato una libreria molto vecchia, che è stata distribuita in un ambiente di produzione, ma il codice sorgente è stato perso.

Ho preso .dll, decompilato e generato progetti e soluzioni. Non sono riuscito a build la soluzione a causa di diversi errori di questo tipo.

I suggerimenti nelle risposte precedenti non sono stati di aiuto, ma dopo un po ‘ho notato mancanze di riferimenti in alcuni progetti a diversi assiemi come System.dll.

Supponiamo che il progetto A dipenda dal progetto B. Non vi era alcun riferimento a System.dll nel progetto B, ma l’errore dopo la compilazione era simile al “Imansible trovare il file Metadata” B.dll “.

Non si è verificato alcun errore in merito alla mancanza di System.dll nel progetto B.

L’aggiunta di riferimenti su librerie come System.dll nel progetto B ha risolto il problema. (System.Data, System.DirectoryServices, ecc.)