O nome não existe no erro de espaço de nomes no XAML

Usando VS2012 trabalhando em um aplicativo VB.NET WPF. Eu tenho um aplicativo tutorial simples MusicPlayer que estou usando para aprender WPF. Eu estou convertendo uma versão c # do tutorial para vb.net passo a passo.

Tem duas classs no aplicativo que estão sob o mesmo namespace. Eu sou capaz de fazer referência ao namespace no XAML, mas quando tento referenciar o object de class no XAML, recebo um erro e não consigo compilar.

O mais estranho é que o IntelliSense funciona bem em referenciar o espaço de nomes através da tag xmlns: c = e também ao digitar o object de class usando <c: Mas o object é sublinhado e erros são gerados tentando construir ou trabalhar no designer.

Os arquivos de class .vb estão em uma pasta chamada \ Controls. O namespace raiz do projeto principal é intencionalmente deixado em branco. A turma é codificada assim …

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

O xaml se parece com isso

(namespace definido na tag

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

(object definido em um )

   

(erro exibido) O nome “UpdatingMediaElement” não existe no namespace “clr-namespace: MusicPlayer.Controls”.

Não tem certeza do que está errado ou como consertá-lo?

Quando você estiver escrevendo seu código wpf e VS, diga que “O nome ABCDE não existe no namespace clr-namespace: ABC”. Mas você pode construir totalmente o seu projeto com sucesso, há apenas um pequeno inconveniente, porque você não pode ver o design da interface do usuário (ou apenas deseja limpar o código).

Tente fazer isso:

  • No VS, clique com o botão direito em sua Solução -> Propriedades -> Propriedades de Configuração

  • Um novo diálogo é aberto, tente alterar as configurações do projeto de Debug para Release ou vice-versa.

Depois disso, reconstrua sua solução. Pode resolver seu problema.

Se a assembly for diferente do namespace no qual sua class está contida, você deverá especificá-la explicitamente.

ex:-

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

Tente alterar a plataforma de destino da compilation para x86 e construir o projeto.

Eu percebi via Subversion que eu aparentemente mudei o alvo da plataforma de compilation do projeto para x64. Essa foi a única mudança que eu fiz. Depois de fazer essa alteração, o código estava funcionando por pouco tempo antes de começar a mostrar o mesmo erro que você experimentou. Mudei o alvo da plataforma para x86 para testar e, de repente, meu designer estava trabalhando novamente. Posteriormente, mudei de volta para x64 e o problema desapareceu completamente. Eu suspeito que o designer cria algum tipo de código em cache no x32 e alterando a plataforma de compilation x64 quebras quando você faz alterações de código.

No meu caso, foi por causa de outros erros de compilation . Quando outros erros foram resolvidos, esse erro aparentemente relacionado também foi removido da lista. Especialmente os erros na parte inferior da lista de erros e nas páginas que você alterou recentemente.

Portanto, não preste atenção a esse erro diretamente e concentre-se em outros erros no início.

Eu vi esse problema desaparecer limpando o Xaml Design Shadow Cache. Eu tive o problema com o Visual Studio 2015 Atualização 1.

No Visual Studio 2015, o Cache está localizado aqui:

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

Processo:

  1. Clique com o botão direito na solução no Solution Explorer e escolha “Clean Solution”
  2. Shutdown Visual Studio
  3. Excluir a pasta do ShadowCache
  4. Reaberto o projeto do Visual Studio
  5. Recriar a solução

E voila não mais erros de namespace.

Não sei se isso vai ajudar alguém

Eu sou novo no WPF e ainda um novato com VB.net – então eu estava assumindo que recebendo este erro estava sendo causado por eu fazendo cimeira boba …….. suponha que eu era realmente! Eu consegui me livrar dele, movendo meu projeto de uma unidade compartilhada para uma das minhas unidades locais. Erro desapareceu, projeto compila perfeitamente sem mais problemas – ainda. Parece VS2015 ainda tem problemas com projetos mantidos em uma unidade compartilhada.

Talvez outra solução para quando o projeto é compilado, mas o erro XAML está aparecendo:

  1. Na solução explore, no nó do projeto que contém o xaml
  2. Clique com o botão direito do mouse no projeto e escolha ‘Descarregar projeto’
  3. Clique com o botão direito no projeto e escolha ‘Reload Project’ Certifique-se de que seu projeto ainda seja escolhido como “projeto de boot”. Se não :
  4. Clique com o botão direito do mouse no projeto e escolha ‘Definir como projeto de boot’

Não há necessidade de reconstruir ou fechar o visual studio.

Jesus … Isso ainda é um problema cinco anos depois no Visual Studio 2017. Como sou novo no WPF, tive certeza de que o problema era de alguma forma eu, mas não, tudo compilado e executado corretamente.

Eu tentei reconstruir, limpar e reconstruir, alternando entre saída x86 / x64, reinicializando o Windows, limpando a pasta ShadowCache, adicionando “; assembly = {my main assembly name}” à declaração de namespace XML, nada funcionou! A única coisa que fez:

Coloque minha class estática de comandos (no meu caso, o negócio era fazer com que o design descobrisse meus comandos do WPF) em sua assembly separada e, em vez disso, alterasse o nome do assembly para esse.

Eu tive o mesmo problema e, no meu caso, o Markup Design View me pediu para reconstruir a solução e não me mostrou o layout do formulário com esta mensagem: Design view is unavailable for x64 and ARM target platforms ou Build the Project to update Design view .

Ele não é resolvido reconstruindo a solução (nem a exibição de design nem o erro “O nome não existe no namespace”)

Eu acho que foi porque eu tinha jogado com as configurações na solução -> Propriedades> Propriedades de configuração

Eu finalmente resolvi o problema com 2 trabalhos:

  1. Marcar todas as checkboxs de seleção na coluna Build da página: Solution -> Properties -> Configuration Properties
  2. Alterando as configurações da solução de Depurar para Liberar ou vice-versa.

Eu acho que é um bug no Visual Studio 2012 Update 2.

O mesmo problema ataca o Visual Studios 2013, Service Pack 4. Eu também tentei com o Visual Studios 2015 Preview com os mesmos resultados.

É apenas uma limitação do visualizador do WPF que a equipe do Visual Studios não corrigiu. Como prova, a construção no modo x86 permite que o visualizador e o edifício no modo x64 o desativem.

Estranhamente, o intellisense funciona para o Visual Studios 2013, Service Pack 4.

Eu tive esse problema recentemente usando o VS 2015 Update 3 para o meu projeto WPF no .NET 4.6.2. A cópia do meu projeto estava em uma pasta de rede , mudei-a localmente e resolvi o problema.

Isso pode resolver outros tipos de problemas, já que o VS 2015 não gosta de caminhos de rede. Outra questão que é um grande problema para eles é a synchronization de repositorys git se meu projeto estiver em um caminho de rede, também resolvido movendo-o localmente.

Parece que este problema pode ser resolvido através de uma variedade de “truques”.

No meu caso, eu estava construindo / reconstruindo / limpando toda a solução, em vez de apenas o projeto no qual eu estava trabalhando na solução. Depois de clicar em “Criar [meu projeto]”, a mensagem de erro desapareceu.

A solução para mim foi desbloquear as DLLs de assembly. As mensagens de erro que você recebe não indicam isso, mas o designer XAML se recusa a carregar o que chama de assemblies “sandboxed”. Você pode ver isso na janela de saída quando você constrói. As DLLs são bloqueadas se forem baixadas da Internet. Para desbloquear suas DLLs de assembly de terceiros:

  1. Clique com o botão direito do mouse no arquivo DLL no Windows Explorer e selecione Propriedades.
  2. Na parte inferior da guia Geral, clique no botão “Desbloquear” ou na checkbox de seleção.

Nota: Somente desbloqueie as DLLs se tiver certeza de que elas são seguras.

No meu caso, o controle de usuário foi adicionado ao projeto principal. Eu tentei várias soluções acima sem sucesso. Ou eu iria receber marcação inválida, mas a solução iria compilar e trabalhar, ou eu iria adicionar o xmlns: c = “clr-namespace: MyProject; assembly = MyProject” e, em seguida, a marcação seria mostrada, mas eu teria um erro de compilation que o tag não existe no namespace XML.

Finalmente, adicionei um novo projeto Biblioteca de Controle de Usuário do WPF à solução e movi meu controle de usuário do projeto principal para esse. Adicionamos a referência e alteramos o assembly para apontar para a nova biblioteca e, finalmente, a marcação funcionou e o projeto foi compilado sem erro.

Eu passei por todas as respostas e nenhuma me ajudou. Finalmente consegui resolvê-lo sozinho, apresentando assim a resposta, pois isso poderia ajudar os outros.

No meu caso, a solução tinha dois projetos, um contendo os modelos (digamos, o nome do projeto e da assembly era Modelos ) e outro contendo as visualizações e modelos de visualização (conforme nossa convenção: projeto, nome do conjunto e namespace padrão eram Models.Monitor ) . O modelo Models.Monitor referiu-se ao projeto Models.

No projeto Models.Monitor, em um dos xaml incluí o seguinte namespace: xmlns: monitor = “clr-namespace: Models.Monitor”

Eu suspeito que MsBuild e Visual Studio, em seguida, estavam errando como eles estavam tentando encontrar um tipo de ‘Monitor’ na assembly ‘Modelos’ . Para resolver tentei o seguinte:

  1. xmlns: monitor = “clr-namespace: Models.Monitor; assembly =” – que é válido se o namespace estiver no mesmo assembly de acordo com https://msdn.microsoft.com/pt-br/library/ms747086(v=vs 0,110) .aspx
  2. também tentei a declaração explícita do namespace: xmlns: monitor = “clr-namespace: Models.Monitor; assembly = Models.Monitor”

Nenhum dos acima funcionou.

Finalmente, desisti e, como um trabalho, movi o UserControl que eu estava tentando usar para outro namespace: ‘ModelsMonitor’ . Eu consegui compilar bem depois disso.

VB.NET não adiciona automaticamente as informações de espaço para nome com base na estrutura de pastas como em C #. Eu acho que estou passando pelo mesmo tutorial que você (Teach Yourself WPF em 24 horas), e fazendo a mesma conversão para VB.

Descobri que você tem que adicionar manualmente as informações de espaço para nome para a class XAML eo código XAML.VB para poder usar os espaços para nome conforme descrito no catálogo. Mesmo assim, o VB não atribui automaticamente o namespace ao assembly como faz no VB.

Há outro artigo aqui que mostra como include isso em seus modelos de projeto para que ele crie as informações do Espaço para Nome automaticamente – Adicionar espaço para nome automaticamente ao adicionar um novo item

Na página de propriedades da solução, verifique a plataforma do assembly que contém “UpdatingMediaElement” e as assmeblies que contêm qualquer uma das superclasss e interfaces das quais “UpdatingMediaElement” subclass ou implementa. Parece que a plataforma de todos esses conjuntos deve ser “AnyCPU”.

Outra causa possível: Um evento de pós-compilation está removendo a DLL do projeto da pasta de compilation.

Para esclarecer: O designer do WPF pode relatar “O nome XXX não existe no namespace …”, mesmo quando o nome existir no namespace e o projeto for compilado e executado bem se um evento de pós-compilation remover a DLL do projeto de a pasta de compilation (bin \ Debug, bin \ Release, etc.). Eu tenho experiência pessoal com isso no Visual Studio 2015.

Ok, então nenhuma dessas dicas funcionou para mim, infelizmente. Eu consegui resolver o problema. Parece que o Visual Studio não funciona bem com unidades de rede. Eu resolvi esse problema movendo o projeto da unidade compartilhada para o meu local e recompilado. Não há mais erros.

Tente verificar suas referências de assembly. Se você tiver um ponto de exclamação amarelo nas referências do projeto, haverá um problema e você receberá todos os tipos de erros.

Se você souber que a referência do projeto está correta, verifique a estrutura de destino. Por exemplo, ter um projeto usando a estrutura 4.5 referencia um projeto com a estrutura 4.5.2 não é uma boa combinação.

Adicionando à pilha.

O meu era o nome do assembly do aplicativo WPF era o mesmo nome do assembly como uma dll referenciada. Portanto, verifique se você não tem nomes de assembly duplicados em nenhum dos seus projetos.

Eu tinha a solução armazenada em um compartilhamento de rede e cada vez que eu abria eu iria receber o aviso sobre fonts não confiáveis. Mudei-o para uma unidade local e o erro “namespace não existe” também desapareceu.

Além disso, tente clicar com o botão direito do mouse em seu projeto -> propriedades e alterar o destino da plataforma para qualquer CPU e reconstruir, então funcionará. Isso funcionou para mim

Adicione um construtor vazio para o seu modelo de visualização e reconstrua a solução. Eu tentei tantas soluções não funcionando, mas isso resolveu para mim.