Errore “File metadati” … \ Release \ project.dll “non trovato in Visual Studio”

Recentemente ho iniziato a ricevere questo messaggio in modo casuale:

Non è stato ansible trovare il file dei metadati “… \ Release \ project.dll” in Visual Studio

Ho una soluzione con diversi progetti in esso. La modalità di generazione corrente è Debug e tutte le configurazioni dei progetti sono impostate su Debug. Ma quando provo a lanciare il progetto principale – a volte mi dà alcuni errori, che sono tutti “File dei metadati” … \ Release \ projectX.dll “non è stato trovato” – e, guarda, dice di RILASCIO cartella, sebbene la modalità corrente sia Debug. Perché? Ho provato a cercare il riferimento a “Release \ projectX.dll” in tutti i file di soluzione e ne ho trovato uno nel file ResolveAssemblyReference.cache.

Ho fatto una buona ricerca su Internet e ho trovato alcune persone con un problema simile, ma non c’era alcuna soluzione, o almeno nessuna soluzione funzionante.

Ho provato a cancellare i riferimenti a quei progetti e leggerli, ma a un certo punto ricomincio a ricevere questi errori.

Sembra un insetto. Perché cerca i progetti di riferimento nelle cartelle di rilascio quando utilizzo sempre la modalità di debug?

PS. Per coloro che hanno incontrato questo problema: non ho potuto risolverlo in modo semplice. È scomparso solo dopo aver reinstallato Windows 🙁

Tutti sono corretti … prova tutto … (in ordine di un po ‘a un sacco di tempo sprecato)

  1. Hai un codice cattivo? Risolvi prima questo.
  2. Pulisci soluzione e riavvia Visual Studio
  3. Rimuovi / aggiungi riferimenti
  4. Controlla il tuo ordine di costruzione con progetti più grandi e verifica
  5. Ricreare manualmente sottoprogetti
  6. Copiare manualmente le DLL tra i progetti nelle cartelle bin associate
  7. Vai a prendere un caffè, giocare a flipper e tornare domani … potresti pensare a qualcos’altro nel frattempo.

Ho avuto lo stesso identico problema. Grande soluzione di studio visivo con oltre 50 progetti.

Tutti i riferimenti sono stati aggiunti come progetti. L’ordine di costruzione del progetto era corretto (fare clic con il tasto destro del mouse sul progetto e selezionare l’ordine di costruzione).

Tuttavia, quando si costruivano alcuni dei progetti di livello più elevato, il progetto “root” da cui dipendevano non veniva costruito.

Il problema era che questi progetti non sono stati selezionati per la configurazione corrente (non so come sia successo).

Per verificare ciò selezionare “Configuration Manager” (menu Build) e verificare se i progetti problematici sono impostati per la compilazione.

Quando dici di aver cancellato i riferimenti a quei progetti e li hai ri-aggiunti, come li hai aggiunti di nuovo, esattamente? Hai usato la scheda “Sfoglia” nella finestra di dialogo “Aggiungi riferimento” in Visual Studio? Oppure, hai usato la scheda “Progetti” (che elenca i progetti vicini nella tua soluzione)?

Modifica : se si utilizza la scheda “Sfoglia” e si aggiunge manualmente il riferimento al file .dll che si trova nella cartella / Release, Visual Studio cercherà sempre il file .dll in quella posizione, indipendentemente dalla modalità in uso attualmente in (Debug o Release).

Se hai rimosso il file .dll effettivo dalla cartella Release (manualmente o facendo “Clean Solution”), il tuo riferimento si interromperà perché il file .dll non esiste.

Suggerirei di rimuovere il riferimento a ProjectX.dll e aggiungerlo di nuovo, ma questa volta, utilizzare la scheda “Progetti” nella finestra di dialogo “Aggiungi riferimento”. Quando aggiungi un riferimento in questo modo, Visual Studio sa dove trovare il file .dll appropriato. Se sei in modalità Debug, lo otterrà dalla cartella / Debug. Se in modalità Release, la cartella / Release. Il tuo errore di compilazione dovrebbe andare via, e inoltre non dovrai più fare riferimento (erroneamente) a un rilascio .dll in modalità Debug.

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

Sezione 1):

In soluzioni generali:

Ho avuto 4 errori di questo tipo (‘file di metadati non è stato trovato’) insieme a 1 errore dicendo ‘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 VS e prova a build di nuovo.

  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 2 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 sopra con varie permutazioni e combinazioni con il riavvio VS poche 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 blog: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

Ho provato i passaggi citati in quel 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 ‘) .


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 .


Ho avuto questo problema prima e l’unico modo per risolverlo è eseguire Clean Solution e riavviare Visual Studio.

Riapri Visual Studio come amministratore.

Per me di solito è il framework di destinazione distriggersto (4.5.2 invece di 4.6) Se si corregge il framework di destinazione del progetto in modo che corrisponda al framework di destinazione della soluzione e si costruisca, verrà creato un nuovo dll.

La maggior parte delle risposte dice che è necessario rimuovere le librerie della soluzione, questo è vero ma quando si aggiungono nuovamente le librerie, l’errore verrà mostrato di nuovo. È necessario verificare se tutte le librerie di riferimento hanno un framework .net compatibile con il framework .net della soluzione. Quindi correggere tutti gli errori nel codice e ribuild la soluzione.

Hai controllato le impostazioni di Configuration manager? Nella finestra di dialogo delle impostazioni del progetto in alto a destra.

A volte capita che tra tutte le voci di rilascio entri una voce di debug. In tal caso, la dipendenza automatica creata dal grafico delle dipendenze della soluzione diventa confusa.

Ho anche visto questo errore in soluzioni in cui ho più progetti (di solito progetti netTiers in cui ho aggiornato uno o più sottoprogetti per il framework 4.0). Può essere problematico da rimuovere. Spesso, tuttavia, può essere risolto risolvendo dapprima tutti gli altri errori nei sottoprogetti (ad esempio, eventuali riferimenti mancanti), ricostruendo singolarmente tali sottoprogetti, quindi rimuovendo / aggiungendo ogni riferimento a tali sottoprogetti in Visual Studio. Personalmente, ho avuto poca fortuna a risolvere questo errore pulendo la soluzione da sola.

Di recente abbiamo riscontrato questo problema dopo l’aggiornamento a Office 2010 di Office 2007: abbiamo dovuto modificare manualmente i riferimenti nel nostro progetto alla versione 14 degli Interops di Office che utilizziamo in alcuni progetti.

Spero che questo ci aiuti – ci sono voluti alcuni giorni per capirlo.

Nel mio caso è stato causato da due cose (VS.2012):

1) Uno dei progetti è stato configurato per AnyCPU anziché x86

2) Un progetto a cui si faceva riferimento aveva in qualche modo la casella di controllo “Crea” deselezionata.

Controlla la tua Build | Configuration Manager per ottenere una panoramica di cosa viene costruito e per quale piattaforma. Assicurati inoltre di controllarlo sia per Debug & Release che potrebbero avere impostazioni diverse.

Nel mio caso, ho avuto alcuni errori nel mio codice. Visual Studio ha mostrato l’errore che avevi invece degli errori effettivi, come errori di syntax o nomi di classi sconosciute. Prova a pulire la soluzione e costruisci il progetto dopo il progetto. In questo modo scoprirai gli errori reali.

Ancora una volta, questo è solo ciò che causa l’errore per me .

Ho avuto questo problema e ho impiegato molto tempo per capirlo. Il problema si è verificato quando ho rimosso i progetti dalla soluzione e ho sostituito quelli con i pacchetti di nuget.

La soluzione sembrava andare bene ma il file .csproj conteneva ancora quei progetti più volte come riferimento.

Sembra che VS non pulisca quel file in modo appropriato. Stava ancora facendo riferimento ai progetti rimossi sotto il cofano. Quando vengono rimossi manualmente i riferimenti dal file csproj, tutto funziona di nuovo! wohoo

Questo problema è dovuto a file pdb o CodeContracts.

Per risolverlo:

  1. Pulisci la tua cartella di output e ricostruisci la soluzione.

  2. Riconfigura i CodeContracts o disabilitalo per la compilazione temporanea.

Abbiamo questo problema abbastanza spesso, ma solo con riferimenti a progetti C ++ / CLI da progetti C #. Ovviamente è un bug in fondo in Visual Studio che Microsoft ha deciso di non risolvere, perché è “troppo complesso” e hanno promesso una revisione del sistema di compilazione C ++ che ora è indirizzato a Visual Studio 2010.

E ‘stato qualche tempo fa, e forse la correzione è arrivata anche in Visual Studio 2008; Non l’ho più seguito. Tuttavia, la nostra tipica soluzione alternativa era

  • Cambia configurazione
  • Riavvia Visual Studio
  • Costruisci la soluzione

Anch’io ho avuto lo stesso problema.

Visual Studio 2013 mi ha solo detto che non poteva fare riferimento ad esso e che non riusciva a trovare i metadati. Quando ho aperto la mia soluzione (che contiene più progetti), ho detto che stavo usando progetti inferiori alla versione framework di uno dei miei progetti.

Così ho cambiato tutto alla versione 4.5, e ha funzionato di nuovo.

Mi sembra di ricordare di avere un problema simile qualche mese fa. L’ho risolto temporaneamente copiando la DLL di riferimento nella cartella Release, soddisfacendo così le aspettative di Visual Studio. Più tardi, ho scoperto il riferimento alla DLL di rilascio nel mio codice attuale. Dovresti provare a fare una ricerca attraverso l’intero progetto per \ release \ project.dll.

Inoltre, ho notato che i progetti di test delle unità di Visual Studio a volte mettono un attributo “DeploymentItem” su ciascuno dei metodi di test che puntano alla DLL di destinazione e, se si passa da Debug a Release, Visual Studio può confondersi se la DLL non è più nella posizione prevista Nella mia esperienza, questi attributi possono essere cancellati in modo sicuro se non li hai inseriti tu stesso come parte di uno scenario di “singola implementazione”.

Ho avuto questo problema ed è stato a causa di un metodo non valido nella libreria incriminata (dll) che non ha restituito un valore, ad es

public bool DoSomething() { //I never bothered putting code here.... } 

Quando ho capito questo, tutto è stato compilato 🙂

A volte VS2010 cambia la mia configurazione da qualsiasi CPU a piattaforms miste. Quando ciò accade, ricevo questo messaggio di errore.

Per risolverlo, torno a qualsiasi CPU:
1. Fare clic con il tasto destro sulla soluzione e selezionare Proprietà.
2. Fare clic su Proprietà di configurazione e quindi su Configuration Manager ….
3. Sotto Piattaforma di soluzioni attive selezionare Qualsiasi CPU

Trovo che questo di solito mi viene in mente quando ho ancora una dichiarazione di metodo in un’interfaccia, che implementa una class, ma che ho rimosso in seguito e ho dimenticato di rimuoverla anche dall’interfaccia. Solitamente mi limito a salvare l’intera soluzione ogni 30 minuti e poi a tornare a una versione precedente se non riesco a trovare l’errore.

Ho finito per cancellare i miei riferimenti (li avevo aggiunti correttamente usando la scheda progetti, e loro erano soliti build bene), modificando manualmente i miei file .csproj e rimuovendo le voci bizzarre che non appartenevano – e impostando i miei output per debug e release, x86 e x64 e tutte le cpu a tutti sono “\ bin” – L’ho costruita una volta, poi ho aggiunto nuovamente il riferimento (di nuovo, usando la scheda progetti), e tutto ha iniziato a funzionare di nuovo per me. Non è stato necessario riavviare Visual Studio.

Per me questo è stato causato dal fatto che il target Build è stato riscritto per non emettere la dll. Rimuovendo questo per ricadere sul target Build predefinito, risolto il problema.

Sembra che accada quando esegui il checkout di una soluzione con più progetti che hanno riferimenti tra di loro e non li hai mai creati prima. Se hai riferimenti direttamente alle DLL, invece di fare riferimento al progetto, riceverai questo messaggio. È sempre necessario utilizzare la scheda Progetti nella finestra di dialogo Aggiungi riferimento per aggiungere un riferimento a un progetto nella stessa soluzione. In questo modo, VS può conoscere l’ordine corretto in cui build la soluzione

lo stesso è successo a me oggi come descritto da Vidar.

Ho un errore di compilazione in una libreria di supporto (a cui fanno riferimento altri progetti) e invece di dirmi che c’è un errore in Helper Library, il compilatore fornisce l’elenco degli errori di tipo MetaFile-not-found. Dopo aver corretto l’errore di compilazione in Helper Library, gli errori MetaFile sono scomparsi.

C’è qualche impostazione in VS per migliorare questo?

Ho avuto lo stesso problema. Ho notato che il mio contesto db (EF4) che si trovava nella dll del progetto non era riconosciuto per qualche motivo. L’ho cancellato e ne ho creato un altro. e questo l’ha risolto per me.

Aveva lo stesso problema oggi.

La mia applicazione, un’applicazione Windows Form, aveva accidentalmente un riferimento a se stessa. Strano.

Una volta rimosso, l’errore è andato via.

Il riferimento è stato aggiunto ogni volta che ho trascinato un modulo di controllo utente, situato nel progetto Windows Form stesso.

Sono d’accordo con la maggior parte delle risposte pubblicate qui. Tuttavia, se tutte le soluzioni suggerite non funzionassero, si consideri che probabilmente si ha un altro tipo di errore nella lista degli errori, che impedisce a VS di build la DLL di un progetto necessaria per gli altri progetti. Quindi, indipendentemente dall’ordine di costruzione o configurazione, non sarai in grado di eliminare l’errore “metadati” finché non verranno risolti gli altri problemi.

CONTROLLA IL TUO PERCORSO DEL PROGETTO. Non dovrebbe avere caratteri irregolari come virgola e spazio

per esempio questo è un percorso errato: d: \ my applications \ Project1

e questo è vero percorso d: \ my_applications \ Project1

Lo studio visivo non può build il progetto quando c’è un carattere non alfabetico e numerico nel suo percorso nel disco e non mostra alcun messaggio per questo errore!

Anche alcuni strumenti di installazione hanno lo stesso problema all’avvio dell’installazione e non possono essere estratti.

Ho avuto lo stesso problema. La rimozione e l’aggiunta manuale delle DLL non ha aiutato. ClassLibraries non è stato compilato per tutti i progetti e mancava nella cartella … \ bin \ Debug per il progetto [perché ho pulito la soluzione per errore]. Poiché la libreria di classi non è stata compilata, ciò significa che potrebbero esserci alcuni errori in uno di questi sottoprogetti .

Soluzione: Poiché le mie DLL erano lì per la cartella … \ bin \ Release , ho provato a ribuild in modalità Release e ho trovato un errore su una riga in uno dei sottoprogetti. Risolvere l’errore e ribuild la soluzione ha eliminato l’errore di compilazione.