il nome non esiste nello spazio dei nomi clr-namespace

Ho una piccola applicazione WPF che è stata compilata bene ma non lo è più. Non posso davvero dire a che punto ha smesso di build. Ha funzionato bene un giorno, e il prossimo non lo è.

Ecco la struttura del progetto:
inserisci la descrizione dell'immagine qui
Non ci sono altri progetti o riferimenti esterni diversi dalle DLL standard .net.

Ecco il controllo utente in cui è stato generato il problema:

      

Ed ecco l’errore che ottengo: http://i48.tinypic.com/5u1u8w.png

Si noti che questo non è solo l’unico file nello screenshot, ma tutti i riferimenti che aggiungo in modo simile in xaml in tutti i file di controllo / finestra utente in questo progetto.

Quindi il file è lì, lo spazio dei nomi nel file è corretto, il nome del namespace / class nel file xaml è (a mio avviso) corretto. Ottengo intellisense quando digito il xaml in modo che trovi i file ok, ma non quando compila.

La soluzione più comune per questo in altri post è stata la versione del framework .net. Attualmente è impostato su .Net Framework 4 per il mio progetto principale e di test. La versione completa non è il profilo del cliente.

Ecco cosa penso di aver incasinato: nel configuration manager, entrambi i progetti hanno la loro piattaforma impostata su Any CPU, ma a un certo punto quando ho cercato di risolvere questo problema ho notato che il progetto principale era impostato su x86 e il progetto di test era impostato su Any PROCESSORE. Quindi ho aggiunto qualsiasi CPU manualmente per il progetto principale nel Configuration Manager. Tuttavia, sinceramente, non so se l’ho fatto correttamente o anche se dovessi farlo. Quindi, come ulteriore domanda, c’è un modo per reimpostare il Configuration Manager sul suo stato predefinito? Avrà qualcosa da dire per il problema principale? Non so se il progetto principale è stato sempre impostato su x86 o no o se in qualche modo l’ho cambiato in x86 e poi si è rotto. Come accennato, questo progetto è stato compilato bene per un po ‘.

Eventuali suggerimenti? Risponderò a domande più dettagliate sul codice o qualsiasi altra cosa come chiedi loro invece di vagare qui 🙂

Ogni volta che mi è successo, ho appena riavviato lo studio visivo, ho ricostruito la soluzione e ha funzionato bene … non so perché

Oltre al messaggio “non esiste nel namespace”, ricevevo anche un messaggio dal progettista che non poteva visualizzare la finestra per i target x64 e ARM.

Ho appena scoperto che passare dalla modalità build alla modalità x86, eseguire una soluzione di ricostruzione, quindi tornare alla modalità x64 e quindi ribuild di nuovo risolve [entrambi] i problemi.

La semplice ricostruzione della soluzione x64 non ha fatto nulla.

Questo è ciò che ha funzionato per me su Visual Studio 2012 (aggiornamento 3).

  • Riavvia Visual Studio
  • Aggiungi assembly corrente alla dichiarazione dello spazio dei nomi xmlns:framework="clr-namespace:TimeRecorder.Framework;assembly=MyAssembly
  • Build -> Build Solution

Quello che ho trovato che mi è stato di aiuto (specialmente se questo errore si verifica in App.xaml ) è di commentare il / i riferimento / i che ti dà problemi, ricostruisci e poi rimuovi i commenti. Penso che ciò che fa è consentire l’intero progetto di build effettivamente invece di fermare la compilazione in caso di errore.

Da ciò che posso raccogliere, l’app sta cercando di creare i file in un determinato ordine, quindi quando App.xaml o presumibilmente qualsiasi altro errore di file di class in un riferimento, il file che causa l’errore non è stato compilato correttamente, quindi perché non trova il file in quello spazio dei nomi.

Ricostruisci la tua soluzione (a volte pulisci e poi costruisci meglio). Poi guarda la tua lista di errori, scorri fino in fondo, e molto probabilmente indicherà un errore che non consente la compilazione del tuo assembly, e il compilatore XAML molto probabilmente userà una versione cache dell’assembly, non quella nuova che tu significa build.

Ho avuto il problema simile. Nel mio caso, ho dovuto fare quanto segue

  • rimuovere il markup di riferimento da xaml (in questo esempio, )
  • build la class (in questo file di esempio che contiene la class HistoryViewModel )
  • Una volta creato, aggiungi il markup di riferimento in xaml
  • build di nuovo

Il metodo sopra ha funzionato per me.

Che cosa ha funzionato per me: – Passare la configurazione della soluzione da Debug a Release – Ripristinare la configurazione da Release a Debug

Nessuna delle soluzioni ha funzionato per me. L’ho risolto in questo modo:

  • Rimuovere la DLL della libreria dai riferimenti
  • Scarica il codice sorgente della libreria (anziché solo il file dll)
  • Costruisci il progetto della biblioteca per ottenere un nuovo file dll
  • Aggiungi il nuovo file dll ai riferimenti del progetto principale

Aveva questo problema andare in tondo sprecando poche ore. Ho spostato una DLL di controllo utente separata nel progetto, quindi è stata compilata nel progetto e non in una DLL di riferimento. Questo ha rotto l’intero progetto, quindi ho controllato meticolosamente tutti gli spazi dei nomi, i percorsi e i nomi dei file. Ho provato a cancellare i file obj, cambiando tra release e debug, tra x86 e AnyCPU. Apertura salvando tutto, ricompilare ancora nessuna gioia.

Ricorda di avere un problema simile prima, l’errore segnalato in VS2013 non era direttamente correlato a dove dovevo modificare lo XAML ma usando

 x:Name="myControl" 

su tutti i controlli, invece di

 Name="myControl" 

aggiustato.

Ecco un esempio strano di una cosa simile:

  ...  

compilerà (VS2013).

  ...  

produce l’errore “tipo Ui non trovato in Gtl.Ui.Gtl” (e ti assicuro che il metodo del gestore esiste nel code-behind). La soluzione consiste nell’aggiungere il gestore nel costruttore della class, ma su Microsoft, cosa sta succedendo?

Ho affrontato lo stesso problema quando stavo cercando di chiamare lo spazio dei nomi in xaml. stava mostrando che la class non è disponibile nello spazio dei nomi. Ho cercato molto. Finalmente ho trovato questo problema era con VS. Sto usando VS 2013. Ho provato i passaggi seguenti:

  1. Build -> Configuration Manager -> Active Solution Platform -> Modificato in x64 e x86 e Any CPU.
  2. Chiuso il VS e aperto di nuovo.
  3. Modificare

     xmlns:VM="clr-namespace:MyFirstAppViewModel" 

    a

     xmlns:VM="clr-namespace:MyFirstAppViewModel;assembly=ViewModel" 

Ho cambiato il framework di destinazione La mia applicazione di “.Net Framework 4.5” a “.Net Framework 4.6” e ha funzionato!

  • mi sento di rinominare x:Key="ViewModel" forse c’è un problema tecnico
  • e se digiti local: VS ti mostra HistoryViewModel ?
  • controlla anche se la tua Class è public

Ran in questo problema oggi con Visual Studio 2017 Community Edition. Ho provato tutti i suggerimenti qui (reset VS 2017, modificato da x64 a x32 e viceversa ecc. Ecc.) E da altre fonti senza successo. Intellisense sa che è tutto lì, ma stavo ricevendo sempre lo stesso errore.

Ad ogni modo, la mia correzione si è rivelata molto semplice … non sono sempre quando hai passato un paio d’ore sul problema!

Fondamentalmente, ho fatto il seguente …

  1. Rimuovi il codice offendente dal file xaml (solo 3 righe nel mio caso)
  2. Costruisci il progetto in modo da ottenere una build di successo
  3. A questo punto il layout è apparso magicamente nella finestra del designer che era un buon segno!
  4. Reinserito il codice che ho rimosso al punto 1. incluso xmlns: entry
  5. A questo punto non dovresti avere alcun scarabocchio blu … speriamo
  6. Costruisci di nuovo il progetto

Sembra che, ottenendo una build di successo, sia necessario ripristinare “qualcosa” all’interno di VS e / o dell’assembly. Una volta che hai una build di successo prova a inserire di nuovo il tuo codice.

Spero che questo aiuti qualcuno fuori 🙂

Basta eseguire l’analisi del codice dal menu Genera

Questo è un problema ricorrente per me. Una volta ho trovato la soluzione nella scheda Avviso . Si trattava di un problema di versione di .NET Framework e affermava quanto segue:

Avviso 9 Non è stato ansible risolvere il riferimento primario “myDll” perché è stato creato rispetto al framework “.NETFramework, Version = v4.5.2”. Questa è una versione superiore rispetto al framework attualmente selezionato “.NETFramework, Version = v4.0”.

C’è un problema tecnico con il loro buffering dei layout degli oggetti. Se qualcosa viene rinominato o spostato, si perde. Ciò che generalmente funziona per me è creare una class completamente nuova e copiare tutto il vecchio codice, farlo funzionare sulla nuova class, quindi rimuovere la class originale. A volte, dopo averlo fatto funzionare con il nuovo nome della class, puoi provare a rinominarlo nuovamente con il nome originale (ma di solito no)

Stavo usando xmlns: local = “using: MyRootNamespace.ChildNamespace” nell’intestazione di .xaml, e l’ho trasformato in xmlns: local = “clr-namespace: MyRootNamespace.ChildNamespace” … beh, ho appena lasciato che l’intellisense faccia il lavoro, e ha funzionato.

Il problema è che quando si crea la destinazione x86, il percorso di output per il particolare progetto è impostato su bin \ x86 \ Debug. Sembra che a Expression la miscela non piaccia affatto. Sembra interessato solo a che cosa è in bin \ debug.

Se hai modificato i tuoi percorsi di output per il progetto x86 in bin \ debug, ad esempio, sono sicuro che troverai che funzionerà. Bene, funziona per me comunque 🙂

Il framework di destinazione del file .dll che aggiungi dovrebbe essere lo stesso del framework di destinazione della tua app.

Questo errore si verifica in genere quando il progetto non è stato creato correttamente durante l’ultima generazione.

Passaggio 1) Per prima cosa rimuovere tutti gli errori che causano il codice dal file XAML o .cs e creare e avviare il progetto premendo F5.

Passaggio 2) Aggiungi aggiungi il tuo errore causando codice in XAML uno per uno.

Ho scoperto che l’esecuzione del comando “Esegui analisi del codice” ricostruisce tutto e quasi sempre risolve il problema (clic destro progetto> Analizza> Esegui analisi del codice). Questo generalmente ricostruisce anche i file delle risorse in modo da poter trovare stringhe, ecc.