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

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?

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.

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"

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.

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 .

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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

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".

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.

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.

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.

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.

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

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).

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

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.

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.