Ottenere “tipo o nome spazio dei nomi non può essere trovato” ma tutto sembra ok?

Sto ricevendo un:

il tipo o il nome dello spazio dei nomi non possono essere trovati

errore per un’applicazione C # WPF in VS2010. Questa area di codice si stava compilando bene, ma all’improvviso sto ricevendo questo errore. Ho provato a rimuovere il riferimento del progetto e l’istruzione using , chiudendo VS2010 e ricominciando, ma ancora ho questo problema.

Qualche idea per cui questo potrebbe accadere, dove sembra che sto facendo la cosa di riferimento riferimento & using dichiarazione?

Ho anche notato in VS2010 che intellisense per quel namespace funziona bene, quindi sembra che VS2010 abbia il riferimento del progetto e veda lo spazio dei nomi da un lato, ma durante la compilazione non lo vede?

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

Può accadere in due modi:

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

Ad esempio, accadrà quando un’applicazione è impostata per indirizzare il framework .Net 4 Client Profile, e il progetto a cui fa riferimento mira al framework .Net completo.

Quindi per rendere più chiaro:

  • Il progetto A si rivolge al framework del profilo del cliente
  • Progetto A fa riferimento a Progetto B
  • Il progetto B riguarda il quadro completo

In questo caso, la soluzione consiste nell’aggiornare la destinazione framework dell’applicazione (Progetto A) o eseguire il downgrade della destinazione dell’assembly di riferimento (Progetto B). Va bene per un’app di framework completo fare riferimento / consumare un assembly del framework del profilo del client, ma non viceversa (il profilo del client non può fare riferimento all’assembly con target completo del framework).

Si noti che è ansible ottenere questo errore anche quando si crea 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 esegue la migrazione da VS2010 a VS2012 o VS2013 e si aggiunge un nuovo progetto)

  • i progetti di riferimento utilizzano una versione più grande, ovvero 4.5.1 o 4.5.3 (hai indirizzato nuovamente i tuoi progetti esistenti alla versione più recente, ma VS crea ancora nuovi progetti indirizzati alla v4.5, e quindi fai riferimento a quei vecchi progetti dal nuovo progetto)

Durante la creazione della soluzione ricevevo lo stesso errore (non è stato ansible trovare il tipo o lo spazio dei nomi “). Sotto di esso ho visto un avviso che indicava che “il riferimento non poteva essere risolto” e per assicurarsi che “l’assieme esistesse su disco”.

Ero molto confuso, perché la mia DLL era molto chiaramente nella posizione a cui puntava il riferimento. VS non sembrava evidenziare alcun errore, fino a quando non ho provato a build la soluzione.

Ho finalmente 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 libreria il mio altro progetto – nella stessa soluzione – che faceva riferimento alla libreria deve aver deciso che la libreria non esisteva)

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

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

Per fare questo:

  1. Ho fatto clic con il pulsante destro sulla soluzione in Esplora soluzioni e 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 è basato sulla libreria e
  4. Selezionata la casella accanto alla libreria trovata sotto “Depends On”

Ciò garantisce che il progetto di libreria sia costruito per primo.

La reinstallazione dei pacchetti di nuget ha funzionato per me. Dopo aver modificato le versioni di .NET Framework per la sincronizzazione di tutti i progetti, alcuni dei pacchetti di nuget (specialmente Entity Framework) erano ancora installati per le versioni precedenti. Questo comando in Packages Manager Console reinstalla i pacchetti per l’intera soluzione:

 Update-Package –reinstall 

Non ho idea del motivo per cui questo ha funzionato, ma ho rimosso il riferimento al progetto che VS2015 mi stava dicendo che non poteva trovare, e l’ho aggiunto di nuovo. Problema risolto. Avevo provato a pulire, build e riavviare VS senza successo.

Innanzitutto vorrei verificare che le informazioni generate dal 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 è aprire un progetto Windows Form, quindi chiuderlo di nuovo. Questo è un po ‘di interiora di pollo, però, quindi non trattenere il respiro.

Una situazione più complicata in cui mi sono imbattuto era: il Progetto uno ha come objective il framework completo 4.0 con il pacchetto Microsoft.Bcl.Async installato. Il progetto due ha come target il framework completo 4.0 ma non si compila quando si fa riferimento a una class Project one.

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

Questo ha funzionato per me. Nella tua class, dove è definito il nome della class, ad esempio: Classe pubblica ABC, rimuovi un personaggio e aspetta un po ‘. La lista degli errori aumenterà perché hai cambiato il nome. Ora rimetti il ​​carattere che hai digitato. Questo ha funzionato per me, spero 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 using che collega a quella cartella ha generato un errore. Nel mio caso, il problema ha avuto origine 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 non sono state in qualche modo aggiornate. Ho provato di tutto: cancellare il file .suo e il cestino e le cartelle obj, pulire la soluzione, ricaricare 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 (il semplice spostamento delle classi nella nuova cartella non è stato di aiuto).

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

Ho riscontrato questo problema durante l’aggiornamento di progetti esistenti da VS2008 a VS2012. Ho scoperto che due progetti (gli unici due che ho creato) avevano come objective diversi .Net Framework (3.5 e 4.0). Ho risolto questo problema nella scheda Applicazione dei progetti assicurandomi che entrambi i progetti avessero “.NET Framework 4” nella casella Target Framework.

Potresti anche provare a eliminare il codice che ritieni di avere problemi e vedere se si compila senza riferimenti a quel codice. In caso contrario, aggiusta le cose fino a quando non ricompila nuovamente, e poi riprova il tuo sospetto problema. A volte ricevo strani errori su classi o metodi che so essere corretti quando il compilatore non ama qualcos’altro. Una volta sistemata la cosa su cui è davvero appesa, questi errori “fantasma” scompaiono.

Abbiamo avuto un caso strano di ciò che ho appena risolto in una soluzione. C’era un carattere nascosto / spazio bianco di fronte a una frase “using” nel progetto principale. Quel progetto andrebbe bene e il sito funzionava bene, ma il progetto di test unitario a cui si riferiva non poteva essere costruito.

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

Vai al progetto che non verrà creato, apri la cartella “Riferimenti” in Esplora soluzioni e verifica se la tua dipendenza è presente nell’elenco.

In caso contrario, puoi “Aggiungi riferimento” e scegliere la dipendenza nella scheda Progetti.

Boom Shankar.

Nel mio caso il problema era che dopo aver cambiato lo spazio dei nomi esattamente nello stesso modo in cui si trovava in un altro progetto (intenzionalmente), il nome dell’assembly è stato modificato anche da VS, quindi c’erano due assembly con lo stesso nome, uno che sovrascriveva l’altro

So che questo sta dando calci a un cavallo morto ma ho avuto questo errore e le strutture dove va bene. Il mio problema stava fondamentalmente affermando che non è stato ansible trovare un’interfaccia, ma è stata creata e acceduta bene. Così ho avuto modo di pensare: “Perché solo questa interfaccia quando gli altri stanno lavorando bene?”

Si è concluso che stavo effettivamente accedendo a un servizio usando WCF con l’interfaccia di un endpoint che usava Entity Versione 6 e il resto dei progetti utilizzava la versione 5. Invece di usare NuGet I semplicemente copiato i pacchetti di 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é molte persone non mescoleranno le versioni di Entity Framework.

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

Nel mio caso ho aggiunto una nuova class a un progetto ma poiché i miei binding di controllo della versione non erano impostati, avevo bisogno di rendere il file scrivibile all’esterno di Visual Studio (tramite VC). Avevo cancellato il salvataggio in Visual Studio ma dopo aver reso il file scrivibile al di fuori di VS, ho quindi premuto Salva tutto nuovamente in VS. Ciò ha inavvertitamente causato il mancato salvataggio del nuovo file di class nel progetto..stato..Intellisense lo mostrava ancora blu e valido nei progetti di riferimento anche se quando provavo a ricompilare il file non veniva trovato e ottenuto il digitare errore non trovato. Chiudere e aprire Visual Studio mostrava ancora il problema (ma se avessi preso nota del file di class che mancava alla riapertura).

Una volta capito, la soluzione era semplice: con il file di progetto impostato su scrivibile, leggeva il file mancante nel progetto. Tutto funziona bene ora.

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 aggiungere nuovamente il riferimento alla DLL, il problema è stato risolto.

Avevo gli stessi errori, la mia storia stava seguendo: dopo una ctriggers fusione (via git) uno dei miei file .csproj aveva duplicato voci di compile come:

    //it's a duplicate 

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

Questo evento si verifica in Visual Studio 2017.

  1. Riavvia Visual Studio
  2. Pulisci il progetto che non riesce a build.
  3. Ricostruisci il progetto.

Ho avuto lo stesso problema come discusso: VS 2017 sottolinea una class nel progetto di riferimento come errore ma la soluzione costruisce ok e funziona anche intellisense.

Ecco come sono riuscito a risolvere questo problema:

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

Nel mio caso ho avuto un file creato da 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 conteneva il trucco per me.

A tutti coloro che ricevono questo errore quando provano a pubblicare il loro sito Web in Azure, nessuna delle soluzioni dall’aspetto promettente in alto mi ha aiutato. Ero nella stessa barca – la mia soluzione si è costruita bene da sola. Ho finito per dover

  1. Rimuovi tutti i pacchetti di nuget nella mia soluzione.
  2. Chiudi e riapri la mia soluzione.
  3. Aggiungere di nuovo tutti i pacchetti di nuget.

Un po ‘doloroso, ma era l’unico modo in cui potevo pubblicare il mio sito Web in Azure.

Ho avuto lo stesso problema. Una notte il mio progetto si sarebbe compilato la mattina successiva ERRORI !.

Alla fine ho scoperto che lo studio visivo ha deciso di “modificare” alcune delle mie referenze e indirizzarle altrove. per esempio:

System.ComponentModel.ISupportInitialize è diventato in qualche modo “blahblah.System.ComponentModel.ISupportInitialize”

Una cosa piuttosto rude per fare vs vs se tu come me

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

Ha funzionato nel mio normale spazio di lavoro e ho potuto aprire il file SLN all’interno della cartella dell’agente e tutto è stato compilato correttamente.

La DLL in questione è stata memorizzata all’interno del progetto come Lib/MyDLL.DLL e fa riferimento con questo nel file csproj:

  False Lib\MYDLL.dll  

Si è scoperto che letteralmente non stava trovando il file nonostante il percorso del suggerimento. Penso che forse msbuild avesse un aspetto relativo al file SLN invece del file di progetto.

In ogni caso, se il messaggio che ottieni è Could not resolve this reference. Could not locate the assembly Could not resolve this reference. Could not locate the assembly quindi assicurarsi che la DLL si trovi in ​​una posizione accessibile a msbuild.

Mi sono in qualche modo imbrogliato e ho trovato un messaggio che diceva Considered "Reference\bin\xxx.dll" e Considered "Reference\bin\xxx.dll" appena copiato le DLL in quel posto.

La mia custodia era la stessa di quella discussa qui, ma non è stata risolta fino a quando non ho rimosso il riferimento System.Core dall’elenco dei riferimenti (Tutto ha funzionato bene senza di esso)

spero che aiuti qualcuno perché questo problema è abbastanza frustrante

Per risolvere questo problema, può anche aiutare a eliminare e ricreare il file *.sln.DotSettings della soluzione associata.

Nel mio caso, l’aggiunta della dll come riferimento ha dato il type or namespace name could not be found errore. Tuttavia, copiare e incollare il file dll direttamente nella cartella bin ha risolto l’errore.

Non ho idea del perché questo ha 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, ho avuto due progetti in una soluzione, ho aggiunto un sottospazio nel 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 realizzata con successo che non avere questo nuovo spazio dei nomi, quindi l’errore era corretto, che non può essere trovato, perché non esisteva. La soluzione era ovviamente quella di correggere gli errori nel progetto di riferimento.

Nel mio caso sono entrato nelle proprietà della soluzione e mi sono assicurato che “Build” fosse stato selezionato nella configurazione per entrambi i progetti. Il mio progetto principale non l’ha fatto controllare.

inserisci la descrizione dell'immagine qui

Rimuovere l’assembly da GAC ​​(cartella C: \ WINDOWS \ assembly: selezionare il comando e fare clic con il pulsante destro del mouse e disinstallare). poiché la soluzione continua a utilizzare refference e se quel guid è in GAC, continuerà a prendere la versione GAC per la compilazione.