Il nome non esiste nell'errore dello spazio dei nomi in XAML


126

Utilizzando VS2012 lavorando su un'applicazione WPF VB.NET. Ho una semplice app tutorial di MusicPlayer che sto usando per imparare WPF. Sto convertendo una versione C # del tutorial in VB.NET passo dopo passo.

Ha 2 classi nell'app che sono entrambe nello stesso spazio dei nomi. Sono in grado di fare riferimento allo spazio dei nomi in XAML ma quando provo a fare riferimento all'oggetto della classe in XAML ottengo un errore e non riesco a compilare.

La cosa strana è che IntelliSense funziona bene sia facendo riferimento allo spazio dei nomi tramite il tag xmlns: c = sia anche quando si digita l'oggetto di classe usando <c: Ma l'oggetto è sottolineato e vengono generati errori nel tentativo di costruire o lavorare nel designer.

I file di classe .vb si trovano in una cartella denominata \ Controls. Lo spazio dei nomi principale del progetto principale è lasciato intenzionalmente in bianco. La classe è codificata in questo modo ...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

Lo xaml si presenta così

(spazio dei nomi definito nel <Window >tag

xmlns:c="clr-namespace:MusicPlayer.Controls"

(oggetto definito in a <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(errore visualizzato) Il nome "UpdateMediaElement" non esiste nello spazio dei nomi "clr-namespace: MusicPlayer.Controls".

Non sai cosa c'è che non va o come risolverlo?


13
Il riavvio del visual ha funzionato per me. (mai sottovalutare il potere di riavviare)
Falaque

1
Un piccolo aiuto per coloro che stanno lottando con questo: assicurati che la tua classe sia pubblica.
Borzh,

Risposte:


234

Quando si scrive il codice WPF e VS, si dice che "Il nome ABCDE non esiste nello spazio dei nomi clr-namespace: ABC". Ma puoi realizzare il tuo progetto totalmente con successo, c'è solo un piccolo inconveniente perché non puoi vedere la progettazione dell'interfaccia utente (o vuoi semplicemente pulire il codice).

Prova a fare questi:

  • In VS, fare clic con il tasto destro del mouse sulla soluzione -> Proprietà -> Proprietà di configurazione

  • Viene aperta una nuova finestra di dialogo, prova a cambiare le configurazioni del progetto da Debug a Release o viceversa.

Successivamente, ricostruisci la tua soluzione. Può risolvere il tuo problema.


4
Questo succede ancora nell'aggiornamento 1. di Visual Studio 2015 La tua soluzione ha funzionato, grazie!
Simon Smith

4
Forse no, ma ho scoperto che il semplice passaggio tra la modalità Debug e la modalità di rilascio sulla barra degli strumenti ha funzionato a prescindere.
ketura,

35
Confermato su VS 2017 versione 15.2 (26430.15) nel luglio 2017. Semplicemente cambiato nel menu a discesa da Debug a Release, compilato e l'errore era sparito, cambiato di nuovo e compilato e l'errore era ancora scomparso.
Tedd Hansen,

7
Sembra che VS17 sia particolarmente testardo - Ho provato a cambiare Rel / Dbg, cambiando x64 / x86, cancellando le cartelle ShadowCache, ComponentCache, Bin / Obj, hanno ancora "errori" e il designer non funziona per questa app molto piccola (altre app con come 50 viste WPF funzionano bene). È successo all'improvviso e non può andare via. Ho avuto questo problema prima di molte volte, ma la prima volta su VS17 e non posso risolverlo ora. Tuttavia questa è la risposta migliore dato che ha funzionato tante volte prima.
bokibeg,

7
Adoro come torno a questa risposta e l'ho già votata, 2,5 anni fa.
Mathieu Guindon,

51

Se l'assembly è diverso dallo spazio dei nomi in cui è contenuta la classe, è necessario specificarlo esplicitamente.

ex:-

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

1
Mentre all'inizio sembrava aver risolto il mio problema, genera comunque lo stesso errore. Tuttavia, ora non sono nemmeno più in grado di creare la soluzione.
Bouke,

6
@bouke Pulisci la soluzione e ricostruiscila
Vasanth Sriram,

Fantastico, grazie. Ciò ha davvero aiutato
Keith

Questo è stato per me. La cosa strana è che i convertitori erano nello stesso assembly del file xaml .... Ma erano su uno spazio dei nomi diverso.
Jonathan Alfaro,

Grazie, l'assemblea mancava.
Bagerfahrer

31

Ho visto risolvere questo problema cancellando Xaml Design Shadow Cache. Ho avuto il problema con Visual Studio 2015 Update 1.

In Visual Studio 2015 la cache si trova qui:

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

Processi:

  1. Fare clic con il tasto destro del mouse sulla soluzione in Esplora soluzioni e selezionare "Soluzione pulita"
  2. Chiudi Visual Studio
  3. Elimina la cartella ShadowCache
  4. Riapre il progetto Visual Studio
  5. Ricostruisci la soluzione

E voilà non più errori nello spazio dei nomi.


7
Purtroppo, non ho cambiato nulla, per me. Ho ancora a che fare con questo fastidioso dopo quasi un anno intero. : /
Khale_Kitha

3
Grazie! Questo ha finito per funzionare per me. È triste vedere che questi trucchi sono ancora necessari in VS15
Ocab19,

4
Puoi usare% localappdata% \ Microsoft \ VisualStudio \ 14.0 \ Designer \ per andare immediatamente nella cartella giusta
Maxence

1
Avere un designer che funziona solo se si crea la soluzione è terribile. Immagina di dire a un designer di automobili di costruire l'intera macchina prima di vedere il design.
Paul McCarthy,

26

Nel mio caso è stato a causa di altri errori di compilazione . Quando altri errori sono stati risolti, anche questo errore apparentemente correlato è stato rimosso dall'elenco. Soprattutto gli errori in fondo all'elenco degli errori e nelle pagine che hai modificato di recente.

Quindi non prestare attenzione direttamente a questo errore e concentrarsi inizialmente su altri errori .


2
Notare che l'esecuzione di una compilazione / compilazione ha risolto questo problema per me, anche se non ho riscontrato altri errori di compilazione non correlati. Sembra che le finestre XAML non siano sempre a conoscenza di nuove classi fino a quando non hai fatto una compilazione.
HK1,

1
Questo è stato il miglior consiglio per me, ma poiché @ HK1 a volte non ci sono altre voci nell'elenco degli errori del compilatore ... non ci sono errori nell'elenco ma ci sono altri errori. Per vederli, commenta o elimina le righe contrassegnate con l'errore dello spazio dei nomi, compila di nuovo e vedrai gli altri errori del compilatore. Modificali e le righe prima contrassegnate con l'errore dello spazio dei nomi andranno bene quando le ripristini.
SERWare,

Avevo rimosso un metodo nel codice che ancora faceva riferimento in XAML. Una volta rimosso il riferimento, questo errore è scomparso.
YarsRevenge13

23

Prova a cambiare la piattaforma di destinazione di build in x86 e a costruire il progetto.

Ho notato tramite Subversion che apparentemente ho cambiato il target della piattaforma di build del progetto in x64. Questa era l'unica modifica che avevo apportato. Dopo aver apportato tale modifica, il codice ha funzionato per un po 'di tempo prima che iniziasse a mostrare lo stesso errore riscontrato. Ho cambiato il target della piattaforma in x86 per testarlo e all'improvviso il mio designer ha lavorato di nuovo. Successivamente, l'ho cambiato in x64 e il problema è completamente scomparso. Ho il sospetto che il designer costruisca una specie di codice memorizzato nella cache in x32 e che la modifica della piattaforma di compilazione x64 la interrompa quando si apportano modifiche al codice.


Ho avuto questo ripetersi e posso confermare che questo risolve il problema per me. È possibile tornare a x64 dopo averlo creato in x86.
teynon,

Questo ha funzionato anche per me in VS 2012 ... dopo ore di tentativi di capire qualcosa di logico. Grazie Tom!
Bryan Greenway,

Il passaggio a x86 e di nuovo a x64 ha risolto il problema qui, quindi grazie per avermi ispirato a provarlo. Avevo persino chiuso VS, cancellato bin e obj e ricostruito, insieme ad altri suggerimenti, e nulla mi ha aiutato fino a questo.
Grault

Sì, questo ha funzionato anche per me su VS2015 Update 2. Tuttavia, era necessario per me ricaricare i miei file dll esterni e ricostruirli anche.
SezMe,

Con VS2015U2, ho ancora questo problema in x64. Funziona alla grande con qualsiasi CPU. Passare avanti e indietro non funziona per me.
DaleyKD,

7

Non so se questo aiuterà qualcun altro

Sono nuovo di WPF e sono ancora alle prime armi con VB.net - quindi stavo assumendo che ottenere questo errore fosse causato da me che facevo lo sciocco del summit ........ supponiamo che lo fossi davvero! Sono riuscito a liberarmene spostando il mio progetto da un'unità condivisa a una delle mie unità locali. L'errore è scomparso, il progetto non compila perfettamente altri problemi - ancora. Sembra che VS2015 abbia ancora problemi con i progetti archiviati su un'unità condivisa.


2
Questo è stato il caso per me, l'ho spostato sul mio VM (su cui sviluppo) e boom senza problemi. Grazie!
Mario Tacke,

Questo è stato il caso anche per me. Spostandoli su un'unità locale (anziché su una condivisione di rete - come impostato da Parallels per unire un po 'sia il file system Mac che Windows), il problema è stato risolto.
ckittel,

7

Forse un'altra soluzione per quando il progetto viene compilato ma viene visualizzato l'errore XAML:

  1. In soluzione esplora, sul nodo del progetto che contiene xaml
  2. Fai clic con il pulsante destro del mouse sul progetto e scegli "Scarica progetto"
  3. Fare clic con il tasto destro del mouse sul progetto e selezionare "Ricarica progetto". Assicurarsi che il progetto sia ancora scelto come "progetto di avvio". Altrimenti :
  4. Fai clic con il pulsante destro del mouse sul progetto e scegli "Imposta come progetto di avvio"

Non è necessario ricostruire o chiudere Visual Studio.


6

Gesù ... Questo è ancora un problema cinque anni dopo in Visual Studio 2017. Dato che sono nuovo in WPF, ero sicuro che il problema fosse in qualche modo me, ma no, tutto è stato compilato ed eseguito correttamente.

Ho provato a ricostruire, pulire e ricostruire, passare dall'output x86 / x64, riavviare Windows, pulire la cartella ShadowCache, aggiungere "; assembly = {il mio nome dell'assembly principale}" alla dichiarazione dello spazio dei nomi XML, niente ha funzionato! L'unica cosa che ha fatto:

Metti la mia classe statica di comandi (nel mio caso l'accordo era di far scoprire al progetto i miei comandi WPF) nel suo assieme separato e cambiare invece il nome dell'assemblaggio in quello.


2

Ho avuto lo stesso problema e, nel mio caso, la vista Progettazione markup mi ha chiesto di ricostruire la soluzione e non mi ha mostrato il layout del modulo con questo messaggio:, Design view is unavailable for x64 and ARM target platformsoppure Build the Project to update Design view.

Non viene risolto ricostruendo la soluzione (né la vista di progettazione né l'errore "Il nome non esiste nello spazio dei nomi")

Penso che sia stato perché avevo giocato con le impostazioni in Soluzione -> Proprietà> Proprietà di configurazione

Alla fine ho risolto il problema con 2 lavori:

  1. Selezionando tutte le caselle di controllo nella colonna Crea della pagina: Soluzione -> Proprietà -> Proprietà di configurazione
  2. Modifica delle configurazioni della soluzione da Debug a Release o viceversa.

Penso che sia un bug nell'aggiornamento 2 di Visual Studio2012.


2

Lo stesso problema affligge Visual Studios 2013, Service Pack 4. L'ho provato anche con Visual Studios 2015 Preview con gli stessi risultati.

È solo una limitazione del visualizzatore WPF che il team di Visual Studios non ha risolto. Come prova, la creazione in modalità x86 abilita il visualizzatore e la creazione in modalità x64 lo disabilita.

L'intellisense stranamente funziona per Visual Studios 2013, Service Pack 4.


2

Di recente ho riscontrato questo problema utilizzando VS 2015 Update 3 per il mio progetto WPF in .NET 4.6.2. La copia del mio progetto era in una cartella di rete , l'ho spostata localmente e questo ha risolto il problema.

Ciò potrebbe risolvere altri tipi di problemi, poiché sembra che VS 2015 non ami i percorsi di rete. Un altro problema che è un grosso problema per loro è la sincronizzazione dei repository git se il mio progetto si trova in un percorso di rete, risolto anche spostandolo localmente.


1

Sembra che questo problema possa essere risolto attraverso una varietà di "trucchi".

Nel mio caso, stavo costruendo / ricostruendo / pulendo l'intera soluzione, anziché solo il progetto a cui stavo lavorando all'interno della soluzione. Dopo aver fatto clic su "Crea [il mio progetto]", il messaggio di errore è scomparso.


1

Prova a verificare i riferimenti dell'assieme. Se hai un punto esclamativo giallo sui riferimenti del progetto, c'è un problema lì e otterrai tutti i tipi di errori.

Se sai che il riferimento al progetto è corretto, controlla il Framework di destinazione. Ad esempio, avere un progetto che utilizza il riferimento al framework 4.5 un progetto con il framework 4.5.2 non è una buona combinazione.


In altre parole, la versione di .NET Framework del progetto non può essere precedente alla versione di .NET Framework del progetto di riferimento.
icernos,

1

La soluzione per me era sbloccare le DLL di assembly. I messaggi di errore che ricevi non indicano questo, ma il designer XAML rifiuta di caricare quelli che chiama assembly "sandboxed". Puoi vederlo nella finestra di output durante la creazione. Le DLL vengono bloccate se vengono scaricate da Internet. Per sbloccare le DLL di assembly di terze parti:

  1. Fare clic con il tasto destro sul file DLL in Esplora risorse e selezionare Proprietà.
  2. Nella parte inferiore della scheda Generale fai clic sul pulsante "Sblocca" o sulla casella di controllo.

Nota: sbloccare le DLL solo se si è sicuri che siano sicure.


Questo ha funzionato per me: avevo scaricato un progetto da Dropbox e stavo ottenendo l'errore. Ho anche dovuto eliminare ShadowCache
geometrikal il

1

Nel mio caso, il controllo utente è stato aggiunto al progetto principale. Ho provato varie soluzioni sopra senza alcun risultato. O otterrei Markup non valido ma la soluzione si compila e funziona, oppure aggiungerei xmlns: c = "clr-namespace: MyProject; assembly = MyProject" e quindi il markup mostrerebbe, ma otterrei un errore di compilazione che il il tag non esiste nello spazio dei nomi XML.

Infine, ho aggiunto un nuovo progetto della libreria di controllo utente WPF alla soluzione e ho spostato il mio controllo utente dal progetto principale a quello. Aggiunto il riferimento e modificato l'assembly per puntare alla nuova libreria e infine il markup ha funzionato e il progetto è stato compilato senza errori.


1

Ho esaminato tutte le risposte e nessuna mi ha aiutato. Finalmente sono stato in grado di risolverlo da solo, presentando così la risposta che potrebbe aiutare gli altri.

Nel mio caso, la soluzione aveva due progetti, uno contenente i modelli (diciamo che il nome del progetto e dell'assieme era Modelli ) e un altro contenente le viste e i modelli di vista (secondo la nostra convenzione: progetto, nome dell'assemblaggio e spazio dei nomi predefinito erano Modelli . Monitor ) . Il progetto Models.Monitor si riferiva a Models.

Nel progetto Models.Monitor, in uno dei xaml ho incluso il seguente spazio dei nomi: xmlns: monitor = "clr-namespace: Models.Monitor"

Ho il sospetto che MsBuild e Visual Studio stessero sbagliando mentre cercavano di trovare un tipo di "Monitor" nell'assemblaggio "Modelli" . Per risolvere ho provato quanto segue:

  1. xmlns: monitor = "clr-namespace: Models.Monitor; assembly =" - che è valido se lo spazio dei nomi è nello stesso assembly come da https://msdn.microsoft.com/en-us/library/ms747086(v=vs .110) aspx
  2. ha anche provato la dichiarazione esplicita dello spazio dei nomi: xmlns: monitor = "clr-namespace: Models.Monitor; assembly = Models.Monitor"

Nessuno dei precedenti ha funzionato.

Alla fine mi sono arreso e, come lavoro, ho spostato UserControl e stavo cercando di usare un altro spazio dei nomi: 'ModelsMonitor' . Sono stato in grado di compilare bene dopo quello.


1

Nel mio caso avevo uno spazio dei nomi e una classe digitati esattamente allo stesso modo, quindi ad esempio uno dei miei spazi dei nomi era

firstDepth.secondDepth.Fubar

che contiene le proprie classi (ad esempio firstDepth.secondDepth.Fubar.someclass)

ma avevo anche una classe " Fubar " nello spazio dei nomi

firstDepth.secondDepth

che si risolve testualmente allo stesso spazio dei nomi Fubar sopra.

Non farlo


1

Nel mio caso il problema era dovuto ad alcuni file fantasma nella directory obj del progetto. Quanto segue risolto il problema per me:

  • Progetto pulito
  • Esci VS
  • rm -rf / obj / *
  • Richiamare VS e ricostruire

1

Ho anche molti problemi con questo! Intellisense mi aiuta a completare lo spazio dei nomi e tutto il resto, ma il compilatore piange. Ho provato tutto quello che ho trovato in questo e in altri thread. Tuttavia, nel mio caso, ciò che ha aiutato alla fine è stato scrivere qualcosa del genere:

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

Lasciare vuoto il nome dell'assembly. Non ho idea del perché. Ma è stato menzionato qui. Devo aggiungere che sto sviluppando un assembly, quindi l'attributo assembly potrebbe avere senso. Ma l'inserimento del nome dell'assembly non ha funzionato. Così strano.


0

VB.NET non aggiunge automaticamente le informazioni sullo spazio dei nomi in base alla struttura delle cartelle come avviene in C #. Penso che sto seguendo il tuo stesso tutorial (Teach Yourself WPF in 24 Hours) e sto facendo la stessa conversione in VB.

Ho scoperto che devi aggiungere manualmente le informazioni sullo spazio dei nomi sia alla classe XAML che al codice XAML.VB per poter utilizzare gli spazi dei nomi come descritto nel libro. Anche in questo caso, VB non assegna automaticamente lo spazio dei nomi all'Assemblea come avviene in VB.

C'è un altro articolo qui che mostra come includerlo nei modelli di progetto in modo da creare automaticamente le informazioni sullo spazio dei nomi - Aggiungi automaticamente lo spazio dei nomi quando aggiungi un nuovo elemento


0

Nella pagina delle proprietà della soluzione, controllare la piattaforma dell'assembly che contiene "UpdateMediaElement" e gli assmeblies che contengono una qualsiasi delle superclassi e interfacce da cui si eseguono le sottoclassi o le implementazioni di "UpdateMediaElement". Sembra che la piattaforma di tutti questi assembly deve essere "AnyCPU".


0

Un'altra possibile causa: un evento post-build sta rimuovendo la DLL del progetto dalla cartella build.

Per chiarire: il designer WPF può riportare "Il nome XXX non esiste nello spazio dei nomi ...", anche quando il nome esiste nello spazio dei nomi e il progetto viene compilato ed eseguito correttamente se un evento post-build rimuove la DLL del progetto da la cartella di compilazione (bin \ Debug, bin \ Release, ecc.). Ho esperienza personale con questo in Visual Studio 2015.


0

Ok, quindi nessuno di questi suggerimenti ha funzionato per me, sfortunatamente. Alla fine sono stato in grado di risolvere il problema. Sembra che Visual Studio non funzioni correttamente con le unità di rete. Ho risolto questo problema spostando il progetto dall'unità condivisa sul mio locale e ricompilato. Niente più errori.


Questa risposta è fornita almeno due volte sopra.
pdschuller,

0

Aggiungendo alla pila.

Il mio era il nome dell'assembly dell'applicazione WPF era lo stesso nome dell'assembly di una DLL di riferimento. Quindi assicurati di non avere nomi di assembly duplicati in nessuno dei tuoi progetti.


0

Avevo la soluzione archiviata su una condivisione di rete e ogni volta che l'ho aperta ricevevo un avviso su fonti non attendibili. L'ho spostato su un'unità locale e anche l'errore "lo spazio dei nomi non esiste" è andato via.


0

Prova anche a fare clic con il tasto destro del mouse sul tuo progetto-> proprietà e cambia il target della piattaforma in Qualsiasi CPU e ricostruiscilo, funzionerà. Questo ha funzionato per me


1
Il tuo suggerimento è un cambiamento significativo che potrebbe non essere nemmeno una possibilità per il PO se si rivolgono a un determinato ambiente. In entrambi i casi è molto improbabile che sia la causa del problema, e se risolvesse il problema per te, suggerirei che il tuo problema reale non corrispondeva alle configurazioni del progetto, che si sarebbe manifestato in molti modi diversi al problema mostrato qui.
LordWilmore,

0

Questo problema può anche essere causato se l'assembly a cui si fa riferimento non viene effettivamente creato. Ad esempio, se il tuo xaml è in Assembly1 e stai facendo riferimento a una classe anche in Assembly1, ma quell'assemblaggio ha errori e non si sta costruendo, questo errore verrà mostrato.

Mi sento sciocco, ma nel mio caso stavo strappando il controllo dell'utente e di conseguenza ho avuto tutti i tipi di errori nelle classi correlate. Mentre stavo tentando di risolverli tutti, ho iniziato con gli errori in questione, non rendendomi conto che xaml si basa su assembly creati per trovare questi riferimenti (a differenza del codice c # / vb che può risolverlo anche prima della compilazione).


0

Ho avuto l'assemblaggio aggiunto come progetto - prima ho eliminato il ddl che è stato aggiunto specificamente ai riferimenti alla dll - che lo ha fatto.


0

Ho questo problema tutto il tempo. Le mie opinioni sono in un progetto della WPF Custom Control Library (una variante della Class Library). Posso fare riferimento a assembly pre-costruiti, ma non posso fare riferimento a nessun codice in un altro progetto della stessa soluzione. Non appena sposto il codice nello stesso progetto di xaml, viene riconosciuto.


0

Nel mio caso, questo problema si verificherà quando l'architettura del programma wpf non è esattamente la stessa con la dipendenza. Supponiamo di avere una dipendenza x64 e un'altra AnyCPU. Quindi se si sceglie x64, il tipo in dll AnyCPU "non esiste", altrimenti il ​​tipo in dll x64 "non esiste". Non puoi emilarli entrambi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.