Ottenere "tipo o nome dello spazio dei nomi non è stato trovato" ma tutto sembra a posto?

Sto ottenendo un:

non è stato possibile trovare il tipo o il nome dello spazio dei nomi

errore per un'app WPF C # in VS2010. Quest'area di codice si stava compilando bene, ma all'improvviso ho riscontrato questo errore. Ho provato a rimuovere il riferimento al progetto e la usingdichiarazione, chiudendo VS2010 e riavviando, ma ho ancora questo problema.

Qualche idea sul perché ciò possa accadere, dove sembra che stia facendo la cosa giusta con riferimento e usingdichiarazione?

Ho anche notato in VS2010 che intellisense per quello spazio dei nomi funziona bene, quindi sembra che VS2010 abbia il riferimento al progetto e stia vedendo lo spazio dei nomi da un lato, ma durante la compilazione non lo vedi?

Questo può essere il risultato di un'incompatibilità della versione del framework .Net tra due progetti.

Può succedere in due modi:

1. un progetto del profilo cliente che fa riferimento a un progetto quadro completo; o
2. una versione di framework precedente destinata a una versione di framework più recente

Ad esempio, accadrà quando un'applicazione è impostata come target per il framework del profilo client .Net 4 e il progetto a cui fa riferimento si rivolge al framework .Net 4 completo.

Quindi, per renderlo più chiaro:

• Il progetto A si rivolge al framework del profilo client
• Progetto A riferimenti Progetto B
• Il progetto B si rivolge al quadro completo

La soluzione in questo caso consiste nell'aggiornamento del target del framework dell'applicazione (Progetto A) o nel downgrade del target dell'assembly di riferimento (Progetto B). Va bene per un'app framework completa fare riferimento / utilizzare un assembly del framework del profilo client, ma non viceversa (il profilo client non può fare riferimento all'assembly target del framework completo).

Nota che puoi anche ottenere questo errore quando crei un nuovo progetto in VS2012 o VS2013 (che utilizza .Net 4.5 come framework predefinito) e:

• i progetti di riferimento utilizzano .Net 4.0 (questo è comune quando si è passati da VS2010 a VS2012 o VS2013 e quindi si aggiunge un nuovo progetto)

• i progetti referenziati utilizzano una versione più grande, ovvero 4.5.1 o 4.5.3 (hai reindirizzato i tuoi progetti esistenti all'ultima versione, ma VS crea ancora nuovi progetti destinati alla v4.5 e quindi fai riferimento a quei progetti più vecchi dal nuovo progetto)

Reinstallare i pacchetti Nuget ha fatto il trucco per me. Dopo aver modificato le versioni di .NET Framework in modo che fossero sincronizzate per tutti i progetti, alcuni pacchetti nuget (in particolare Entity Framework) erano ancora installati per le versioni precedenti. Questo comando nella console di Gestione pacchetti reinstalla i pacchetti per l'intera soluzione:

Update-Package –reinstall

Non ho idea del perché abbia funzionato, ma ho rimosso il riferimento al progetto che VS2015 mi stava dicendo che non riusciva a trovare e l'ho aggiunto di nuovo. Problema risolto. Avevo provato a ripulire, costruire e riavviare VS senza alcun risultato.

Durante la creazione della soluzione ho riscontrato lo stesso errore (non è stato possibile trovare il tipo o lo spazio dei nomi ''). Sotto di esso ho visto un avvertimento in cui si afferma che "il riferimento non può essere risolto" e per assicurarsi che "l'assembly esiste sul disco".

Ero molto confuso, perché la mia DLL si trovava molto chiaramente nella posizione indicata dal riferimento. VS non ha evidenziato alcun errore, fino a quando non ho provato a creare la soluzione.

Alla fine ho capito il problema (o almeno quello che sospetto fosse il problema). Stavo costruendo il file della libreria nella stessa soluzione. Quindi, anche se esisteva sul disco, veniva ricostruito in quella posizione (in qualche modo nel processo di ricostruzione della biblioteca il mio altro progetto - nella stessa soluzione - che faceva riferimento alla biblioteca doveva aver deciso che la biblioteca non esisteva)

Quando ho fatto clic con il pulsante destro del mouse sul progetto e ho creato solo quello, anziché l'intera soluzione, non ho riscontrato l'errore.

Per risolvere questo problema ho aggiunto la libreria come dipendenza al progetto che la stava usando.

Per fare questo:

1. Ho fatto clic con il tasto destro sulla mia soluzione in Esplora soluzioni e ho selezionato "Proprietà"
2. Quindi in "Proprietà comuni" ho selezionato "Dipendenze del progetto".
3. Quindi nel menu a discesa Progetti ho selezionato il progetto che si basava sulla libreria e
4. Ho selezionato la casella accanto alla libreria trovata in "Dipende da"

Ciò garantisce che il progetto della biblioteca venga creato per primo.

Innanzitutto verificherei che le informazioni generate dal tuo progetto non siano corrotte. Fai una pulizia e ricostruisci la tua soluzione.

Se ciò non aiuta, una cosa che ho visto lavorare in passato per problemi di progettazione è l'apertura di un progetto Windows Form, quindi la richiude. Questo è un po 'di pollo-interiora, tuttavia, quindi non trattenere il respiro.

Una situazione più complicata in cui mi sono imbattuto è stata: il progetto uno ha come obiettivo il framework completo 4.0 Microsoft.Bcl.Async pacchetto installato. Il progetto due si rivolge al framework completo 4.0 ma non si compila quando fa riferimento a una classe Progetto uno.

Una volta installato il pacchetto NuGet Async sul secondo progetto, è stato compilato correttamente.

Nel mio caso, trovo che il riferimento in VisualStudio abbia un triangolo e un punto esclamativo come questa immagine,

quindi, faccio clic con il pulsante destro del mouse per rimuoverlo e aggiungo nuovamente il riferimento dll correttamente, il problema è stato risolto.

Questo ha funzionato per me. Nella tua classe, dove viene definito il nome della classe, ad esempio: Classe pubblica ABC, rimuovi un carattere e attendi un po '. La tua lista errori aumenterà perché hai cambiato il nome. Ora rimetti il ​​personaggio che hai digitato. Questo ha funzionato per me, si spera che funzionerà anche per te. In bocca al lupo!!!

Ho avuto un problema simile: il compilatore non è stato in grado di rilevare una cartella all'interno dello stesso progetto , quindi una direttiva che utilizzava il collegamento a quella cartella ha generato un errore. Nel mio caso, il problema è nato dalla ridenominazione della cartella . Anche se ho aggiornato lo spazio dei nomi di tutte le classi all'interno di quella cartella, le informazioni sul progetto in qualche modo non sono state aggiornate. Ho provato di tutto: eliminando il file .suo e le cartelle bin e obj, ripulendo la soluzione, ricaricando il progetto, nulla ha aiutato. Ho risolto il problema eliminando la cartella e le classi all'interno, creando una nuova cartella e creando nuove classi in quella nuova cartella (semplicemente spostare le classi all'interno della nuova cartella non ha aiutato).

PS: Nel mio caso stavo lavorando su un'applicazione web, ma questo problema può verificarsi in diversi tipi di progetti.

[Facepalm] Il mio problema era che avevo aggiunto la dipendenza nel modo di fare le cose in C ++.

Vai al progetto che non verrà compilato, apri la cartella "Riferimenti" in Esplora soluzioni e verifica se la tua dipendenza è elencata.

In caso contrario, è possibile 'Aggiungi riferimento' e scegliere la dipendenza nella scheda Progetti.

Boom Shankar.

Abbiamo avuto uno strano caso di questo che ho appena risolto in una soluzione. C'era un carattere nascosto / bianco davanti a un'istruzione "using" nel progetto principale. Quel progetto avrebbe funzionato bene e il sito Web avrebbe funzionato bene, ma il progetto di unit test a cui faceva riferimento non poteva essere realizzato.

Ho riscontrato questo problema durante l'aggiornamento di progetti esistenti da VS2008 a VS2012. Ho scoperto che due progetti (i soli due che ho creato) avevano come target diversi .Net Frameworks (3.5 e 4.0). Ho risolto questo problema nella scheda Applicazione dei progetti assicurandomi che entrambi i progetti contenessero ".NET Framework 4" nella casella Target Framework.

Ho avuto gli stessi errori, la mia storia era la seguente: dopo una cattiva fusione (tramite git) uno dei miei file .csproj aveva compilevoci duplicate come:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

Se hai una grande soluzione e più di 300 messaggi nella finestra degli errori è difficile rilevare questo problema. Quindi ho aperto il file .csproj danneggiato tramite il blocco note e rimosso voci duplicate. Ha funzionato nel mio caso.

Ho avuto lo stesso problema di cui ho discusso: VS 2017 sottolinea una classe nel progetto di riferimento come errore, ma la soluzione crea ok e persino l'intellisense funziona.

Ecco come sono riuscito a risolvere questo problema:

1. Scarica il progetto referenziato
2. Apri il file .proj in VS (stavo cercando duplicati come qualcuno ha suggerito qui)
3. Ricarica di nuovo il progetto (non ho modificato o salvato il file proj perché non avevo duplicati)

Potresti anche provare a eliminare il codice con cui pensi di avere problemi e vedere se si compila senza riferimenti a quel codice. In caso contrario, correggi le cose fino a quando non viene compilato di nuovo, quindi reinvia il tuo sospetto codice di problema. A volte ricevo strani errori su classi o metodi che so essere corretti quando al compilatore non piace qualcos'altro. Una volta risolto il problema a cui si sta davvero bloccando, questi errori "fantasma" scompaiono.

So che questo sta dando dei calci a un cavallo morto, ma ho avuto questo errore e le strutture dove andavano bene. Il mio problema era fondamentalmente affermare che non è stato possibile trovare un'interfaccia, ma è stata creata e acceduta bene. Quindi ho pensato: "Perché solo questa interfaccia quando gli altri funzionano bene?"

Alla fine stavo effettivamente accedendo a un servizio usando WCF con un'interfaccia endpoint che utilizzava Entity Versione 6 e il resto dei progetti utilizzava la versione 5. Invece di usare NuGet ho semplicemente copiato i pacchetti nuget in un repository locale per il riutilizzo e li ha elencati in modo diverso.

ad esempio EntityFramework6.dll contro EntityFramework.dll .

Ho quindi aggiunto i riferimenti al progetto client e poof, il mio errore è andato via. Mi rendo conto che questo è un caso limite poiché la maggior parte delle persone non mescolerà le versioni di Entity Framework.

Aggiungere la mia soluzione al mix perché era un po 'diverso e mi ci è voluto un po' di tempo per capire.

Nel mio caso ho aggiunto una nuova classe a un progetto, ma poiché non sono stati impostati i collegamenti del controllo della versione, è necessario rendere il file scrivibile all'esterno di Visual Studio (tramite VC). Avevo annullato il salvataggio in Visual Studio, ma dopo aver reso il file scrivibile all'esterno di VS, ho nuovamente premuto Salva tutto in VS. Ciò ha inavvertitamente fatto sì che il nuovo file di classe non venisse salvato nel progetto ... tuttavia ... Intellisense lo mostrava ancora come blu e valido nei progetti di riferimento anche se quando provavo a ricompilare il file non è stato trovato e ho ottenuto il tipo non trovato errore. La chiusura e l'apertura di Visual Studio mostravano ancora il problema (ma se avessi preso nota del file di classe mancava alla riapertura).

Una volta capito questo, la correzione è stata semplice: con il file di progetto impostato su scrivibile, ho letto il file mancante sul progetto. Ora tutto va bene.

Ho avuto lo stesso problema. Una notte il mio progetto si sarebbe compilato il mattino dopo ERRORI !.

Alla fine ho scoperto che Visual Studio ha deciso di "modificare" alcuni dei miei riferimenti e di indicarli altrove. per esempio:

System.ComponentModel.ISupportInitialize in qualche modo è diventato "blahblah.System.ComponentModel.ISupportInitialize"

Piuttosto una cosa scortese da fare per il vs se come me

L'evento si verifica in Visual Studio 2017.

1. Riavvia Visual Studio
2. Progetto pulito che non riesce a costruire.
3. Ricostruisci il progetto.

Il mio caso era lo stesso di quello discusso qui, ma nulla ha risolto fino a quando non ho rimosso il System.Core riferimento dall'elenco dei riferimenti (tutto ha funzionato bene senza di esso)

spero che possa aiutare qualcuno perché questo problema è abbastanza frustrante

Per risolvere questo problema, può anche essere utile eliminare e ricreare il *.sln.DotSettingsfile della soluzione associata.

Nel mio caso avevo una Classe che era elencata nella cartella di origine corretta, ma non si registrava in Esplora soluzioni. Ho dovuto fare clic con il pulsante destro del mouse sul progetto> Aggiungi elemento esistente e selezionare manualmente quella classe che diceva che mancava. Quindi tutto ha funzionato bene!

Nel mio caso il problema era che dopo aver cambiato lo spazio dei nomi esattamente come in un altro progetto (intenzionalmente), anche il nome dell'assembly veniva cambiato da VS, quindi c'erano due assembly con lo stesso nome, uno che sostituiva l'altro

Nel mio caso avevo un file creato dalla dipendenza esterna (xsd2code) e in qualche modo i suoi file designer.cs non sono stati elaborati da VS correttamente. Creare un nuovo file in Visual Studio e incollare il codice in esso ha funzionato per me.

A chiunque stia riscontrando questo errore quando provano a pubblicare il loro sito Web in Azure, nessuna delle soluzioni più promettenti sopra mi ha aiutato. Ero nella stessa barca - la mia soluzione è stata costruita bene da sola. Ho finito per farlo

1. Rimuovi tutti i pacchetti nuget dalla mia soluzione.
2. Chiudi e riapri la mia soluzione.
3. Aggiungi nuovamente tutti i pacchetti nuget.

Un po 'doloroso, ma è stato l'unico modo in cui ho potuto pubblicare il mio sito Web in Azure.

Ho riscontrato questo errore nel tentativo di creare una build con una build di Visual Studio Team Services in esecuzione sul mio computer locale come agente.

Funzionava perfettamente nel mio normale spazio di lavoro e sono stato in grado di aprire il file SLN nella cartella dell'agente localmente e tutto compilato correttamente.

La DLL in questione è stata memorizzata all'interno del progetto come Lib/MyDLL.DLLe riferimenti con questo nel file csproj:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

Si è scoperto che letteralmente non riusciva a trovare il file nonostante il percorso di suggerimento. Penso che forse msbuild sembrasse relativo al file SLN anziché al file di progetto.

In ogni caso, se il messaggio che ricevi è, Could not resolve this reference. Could not locate the assemblyassicurati che la DLL sia in una posizione accessibile a msbuild.

In un certo senso ho imbrogliato e ho trovato un messaggio che diceva Considered "Reference\bin\xxx.dll"e ho semplicemente copiato le DLL lì.

Nel mio caso, l'aggiunta della dll come riferimento ha dato l' type or namespace name could not be founderrore. Tuttavia, copiando e incollando il file dll direttamente nella cartella bin è stato risolto l'errore.

Non ho idea del perché abbia funzionato.

So che questo thread è vecchio ma, comunque, sto condividendo, devo installare tutte le dipendenze di terze parti dell'assembly importato - poiché l'assembly importato non è stato incluso come pacchetto Nuget, quindi mancavano le sue dipendenze.

Hop questo aiuto :)

Nel mio caso, avevo due progetti in una soluzione, ho aggiunto uno spazio dei nomi secondari al progetto di riferimento, ma durante la creazione non ho notato che la creazione del progetto di riferimento non è riuscita e ha utilizzato l'ultima versione creata correttamente che non ha avere questo nuovo spazio dei nomi, quindi l'errore era corretto, che non poteva essere trovato, perché non esisteva La soluzione era ovviamente quella di correggere gli errori nel progetto di riferimento.

Stavo lavorando su VS 2017 Community Edition e ho avuto lo stesso problema con i pacchetti nuget CefSharp.

I pacchetti sono stati scaricati e ripristinati correttamente, il progetto può essere creato ed eseguito correttamente - solo il markup ha indicato che gli spazi dei nomi non sono stati riconosciuti.

Tutto quello che dovevo fare era aprire la Referencessezione e fare clic su uno dei punti esclamativi gialli.

Dopo alcuni secondi gli errori di markup sono scomparsi.