Impossibile trovare il file di 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

Ecco come faccio riferimento ai miei controlli utente:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

Succede dopo ogni build fallita. L'unico modo per ottenere la soluzione da compilare è commentare tutti i miei controlli utente e ricostruire il progetto, quindi decomprimere i controlli utente e tutto va bene.

Ho verificato gli ordini di compilazione e le configurazioni delle dipendenze.

Come puoi vedere, sembra aver troncato il percorso assoluto del file DLL ... Ho letto che esiste un bug con la lunghezza. È un possibile problema?

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

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

Istruzioni scritte:

1. Fare clic con il tasto destro sulla soluzione e fare clic su Proprietà.
2. Fai clic su Configurazione a sinistra.
3. Assicurati che la casella di controllo in "Crea" per il progetto che non trova sia selezionata. Se è già selezionato, deseleziona, premi applica e seleziona nuovamente le caselle.
4. (Facoltativo) È stato necessario eseguire entrambe le modalità Release e Debug sulle proprietà della soluzione.

Istruzioni per la cattura dello schermo:

• Dicono che un'immagine vale più di mille parole. Fai clic sulla GIF per ingrandire e, si spera, sarà facile da seguire:

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

Un'altra cosa da provare è chiudere Visual Studio ed eliminare il .suofile accanto al .slnfile. (Verrà rigenerato la prossima volta Save all(o uscirà da Visual Studio)).

Ho avuto questo problema quando ho aggiunto nuovi progetti alla soluzione su un altro computer e poi ho inserito le revisioni, ma il .suofile può essere danneggiato anche in altri casi e portare a un comportamento molto strano di Visual Studio, quindi eliminarlo è uno dei cose che provo sempre.

Si noti che l'eliminazione del .suofile reimposterà i progetti di avvio della soluzione.

Maggiori informazioni sul .suofile 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 segnalato come un avvertimento dal compilatore, ma stava causando il fallimento dell'edificio. Questo avrebbe dovuto essere segnalato come un errore e non come un avvertimento.

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

Sezione 1):

In generale soluzioni:

Ho avuto quattro errori di questo tipo ("Impossibile trovare il file dei metadati") insieme a un errore che diceva "Impossibile aprire il file di origine (" Errore non specificato ")".

Ho cercato di eliminare l'errore "Impossibile trovare il file dei metadati". Per questo, ho letto molti post, blog, ecc. E ho scoperto che queste soluzioni potrebbero essere efficaci (riassumendole qui):

1. Riavvia Visual Studio e prova a creare di nuovo.

2. Vai a "Esplora soluzioni" . Fare clic con il tasto destro su Soluzione. Vai a Proprietà . Vai a "Configuration Manager" . Controlla se le caselle di controllo in "Build" sono selezionate o meno. Se alcuni o tutti sono deselezionati, quindi controllali e prova a ricostruire.

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

4. Ordine di costruzione e dipendenze del progetto:

   Vai a "Esplora soluzioni" . Fare clic con il tasto destro su Soluzione. Vai a "Dipendenze del progetto ..." . Vedrai due schede: "Dipendenze" e "Ordine di costruzione" . Questo ordine di compilazione è quello in cui si sviluppa la soluzione. Controllare le dipendenze del progetto e l'ordine di costruzione per verificare se un progetto (ad esempio "progetto1") che dipende da altri (ad esempio "progetto2") sta provando a costruire prima di quello (progetto2). Questa potrebbe essere la causa dell'errore.

5. Controlla il percorso del DLL mancante:

   Controlla il percorso del DLL mancante. Se il percorso contiene spazio o qualsiasi altro carattere di percorso non valido, rimuovilo e prova a ricostruire.

   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 eliminare altri errori che stavo riscontrando ("Impossibile aprire il file di origine (" Errore non specificato ")").

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

Ho provato i passaggi menzionati in quel post sul blog e mi sono liberato dell'errore "Impossibile aprire il file di origine (" Errore non specificato ")" e sorprendentemente mi sono liberato di altri errori ("impossibile trovare il file dei metadati") come bene.

Sezione (3):

Morale della storia:

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

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

Un progetto era 3.5 e l'altro progetto di riferimento 4.6.1.

Chiudere e riaprire Visual Studio 2013 ha funzionato per me!

Bene, nulla nelle risposte precedenti ha funzionato per me, quindi mi ha fatto pensare al motivo per cui sto facendo clic e sperando quando come sviluppatori dovremmo davvero provare a capire cosa sta succedendo qui.

Mi è sembrato ovvio che questo errato riferimento al file dei metadati debba essere tenuto da qualche parte.

Una rapida ricerca del file .csproj mostrava le righe colpevoli. Avevo una sezione chiamata <itemGroup> che sembrava sospesa sul vecchio percorso file errato.

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

Quindi una soluzione semplice davvero:

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

Si prega di assicurarsi di eseguire il backup del vecchio .csproj prima di giocherellare .

Ho anche riscontrato questo problema. Innanzitutto devi creare manualmente il tuo progetto DLL, facendo clic con il tasto destro del mouse su Build. Quindi funzionerà.

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

Se il percorso della tua soluzione è simile a "Il mio progetto% 2c Molto popolare% 2c Test unità% 2c Software e Hardware.zip", non è possibile risolvere il file di metadati, forse dovremmo impedire alcune parole non valide come% 2c.

Rinominare il percorso con il nome normale ha risolto il mio problema.

Ho avuto lo stesso errore "Impossibile trovare il file dei metadati '.dll'" e ho provato diverse cose descritte sopra, ma la ragione dell'errore era che mi riferivo a un file DLL di terze parti che aveva come target una versione .NET successiva che il mio progetto ha come destinazione la versione .NET. Quindi la soluzione è stata quella di cambiare il quadro di riferimento del mio progetto.

Visual Studio 2019 ha funzionato per me:

1. Chiudi Visual Studio
2. Elimina la .vscartella nascosta
3. Riaprire Visual Studio e ricostruire la soluzione.

Per me, stava cercando 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 verso il progetto, ma Visual Studio in qualche modo continuava a cercare nella vecchia posizione.

Soluzione: rinominare ogni problema Progetto - basta aggiungere un carattere o altro - quindi rinominarlo con il nome originale.

Questo deve reimpostare un po 'di cache globale di qualche tipo in Visual Studio, perché questo risolve sia questo problema che molti simili, mentre cose come Clean non lo fanno.

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

La ragione? Il progetto che ho presentato era rivolto a un diverso framework .NET (4.6 e i miei altri due erano 4.5.2).

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

Visual Studio seleziona automaticamente .NET Framework 4.5.

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

Per me i seguenti passaggi hanno funzionato:

• Trova il progetto che non sta costruendo
• Rimuovere / aggiungere riferimenti a progetti all'interno della soluzione.

Mi stavo anche togliendo i capelli con questo problema, ma dopo aver provato le risposte precedenti l'unica cosa che funzionava 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 questa è stata compilata correttamente.

È strano, perché se avessi fatto clic su ciascun progetto in Esplora soluzioni e avessi provato a crearli in quel modo, tutti avrebbero fallito. Ho dovuto aprirli da soli nelle loro soluzioni.

Sembra che questo tipo di errori sia dovuto al fatto che Visual Studio non fornisce informazioni corrette su un errore. Lo sviluppatore non capisce nemmeno il motivo della build fallita. Può essere un errore di sintassi o qualcos'altro. In comune, per risolvere tali problemi dovresti trovare la radice del problema (ad esempio, guarda il registro di build).

Nel mio caso il problema era in effetti che la Error Listfinestra non mostrava alcun errore. Ma c'erano davvero errori di sintassi; Ho trovato questi errori nella Outputfinestra e, dopo averli risolti, il problema è stato risolto.

La mia istanza del problema è stata causata da un progetto comune che conteneva un nome di classe duplicato (con un nome file diverso). È strano che Visual Studio non sia stato in grado di rilevarlo e abbia semplicemente fatto saltare il processo di generazione.

Ho riscontrato questo problema in Visual Studio 2012 in una soluzione con molti progetti. La ricostruzione manuale di ogni progetto nella soluzione nello stesso ordine di Ordine di costruzione del progetto (tasto destro e ricostruzione in Esplora soluzioni) l'ha risolto per me.

Alla fine ne sono arrivato uno che mi ha dato un errore di compilazione. Ho corretto l'errore e la soluzione sarebbe stata compilata correttamente dopo.

Nel mio caso il problema era che avevo eliminato manualmente un file di non compilazione che era contrassegnato come "mancante". Una volta ho eliminato il riferimento al file mancante e ricompilato: tutto andava bene.

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

Tornando a questo alcuni anni dopo, questo problema è più che probabilmente correlato al limite massimo del percorso di Windows:

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

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

errore CS0067: l'evento 'XYZ' non viene mai utilizzato

che, per qualsiasi motivo, non è stato visualizzato nella finestra dell'errore.

Per questo motivo, il sistema di compilazione di Visual Studio sembrava mancare l'errore e ha cercato di costruire progetti dipendenti, che a loro volta hanno fallito con il fastidioso messaggio di metadati.

La raccomandazione è -come stupida come può sembrare-:

Dai un'occhiata alla finestra di output !

Mi ci è voluta mezz'ora prima che questa idea mi colpisse ...

Anch'io ho avuto lo stesso errore. Si nasconde come nel percorso seguente. Il percorso a cui ho fatto riferimento per il file DLL è simile a "D: \ Assemblies Folder \ Assembly1.dll".

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

A causa di questa variazione del nome del percorso, l'assembly non è stato recuperato dal suo percorso originale e quindi genera l'errore "Metadata not found".

La soluzione è nella domanda di overflow dello stack Come posso sostituire tutti gli spazi con% 20 in C #? .

Avevo affrontato lo stesso problema. Nel mio caso avevo fatto riferimento a un progetto di libreria di classi con una versione .Net superiore rispetto al mio progetto e VS non è riuscito a creare il progetto e ha generato lo stesso errore che hai postato.

Ho semplicemente impostato la versione .Net del mio progetto di libreria di classi (quella che aveva rotto la build) identica alla versione .Net del progetto di riferimento e il problema è stato risolto.

Sottolineamo palesemente ovvio: se non hai abilitato "Mostra finestra di output all'avvio della build", assicurati di notare se la tua build non sta funzionando (piccolo errore "build fail" in basso a sinistra) !!!!

Ho riscontrato questo errore durante il tentativo di pubblicare un'applicazione Web. Si è scoperto che era inclusa una delle proprietà di una classe

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

ma l'uso della proprietà non lo era. La pubblicazione è stata fatta in configurazione Release senza il DEBUGsimbolo, ovviamente.

Sulla base del messaggio di errore, non credo che il percorso del file venga troncato. Sembra essere semplicemente errato. Se sto leggendo correttamente il messaggio, sembra che stia cercando il file DLL su ...

LAVORO = - \ Tools \ VersionManagementSystem \ BusinessLogicLayer \ bin \ Debug \ BusinessLogicLayer.dll

Questo non è un percorso valido. È possibile che nel processo di compilazione sia impostata una definizione di macro su un valore non valido?

Ho avuto questo problema perché .nuget\NuGet.exenon era incluso nel mio repository. Sebbene abbia abilitato DownloadNuGetExeNuGet.targets, ha riscontrato un errore proxy durante il tentativo di scaricarlo. Ciò ha causato il fallimento del resto delle build del progetto.

Questo errore può essere visualizzato se si utilizzano assembly falsi. La rimozione dei falsi porta alla creazione corretta del progetto.