Não foi possível encontrar o "tipo ou nome do namespace", mas tudo parece ok?

Estou recebendo um:

Não foi possível encontrar o tipo ou o nome do espaço para nome

erro para um aplicativo C # WPF no VS2010. Essa área do código estava compilando bem, mas de repente estou recebendo esse erro. Tentei remover a referência do projeto e a usinginstrução, fechando o VS2010 e reiniciando, mas ainda tenho esse problema.

Alguma idéia de por que isso pode estar ocorrendo, onde parece que estou fazendo a coisa certa using? Referência e declaração?

Também observei no VS2010 que o intellisense para esse namespace está funcionando bem, então parece que o VS2010 tem a referência do projeto e está vendo o namespace por um lado, mas durante a compilação não o vê?

Isso pode ser o resultado de uma incompatibilidade da versão da estrutura .Net entre dois projetos.

Isso pode acontecer de duas maneiras:

1. um projeto de perfil de cliente referenciando um projeto de estrutura completo; ou
2. uma versão mais antiga da estrutura visando uma versão mais recente da estrutura

Por exemplo, isso acontecerá quando um aplicativo estiver definido para atingir a estrutura do perfil do cliente .Net 4 e o projeto a que ele se refere atingir a estrutura completa da .Net 4.

Então, para deixar isso mais claro:

• O Projeto A tem como alvo a estrutura do Perfil do Cliente
• O Projeto A faz referência ao Projeto B
• O Projeto B tem como alvo todo o quadro

A solução nesse caso é atualizar o destino da estrutura do aplicativo (Projeto A) ou fazer o downgrade do destino do assembly referenciado (Projeto B). Não há problema em um aplicativo de estrutura completa referenciar / consumir um assembly de estrutura de perfil de cliente, mas não o contrário (o perfil de cliente não pode fazer referência a assembly direcionado à estrutura completa).

Observe que você também pode obter esse erro ao criar um novo projeto no VS2012 ou no VS2013 (que usa o .NET 4.5 como a estrutura padrão) e:

• os projetos de referência usam .Net 4.0 (isso é comum quando você migrou do VS2010 para o VS2012 ou VS2013 e depois adicionou um novo projeto)

• os projetos referenciados usam uma versão maior, ou seja, 4.5.1 ou 4.5.3 (você redirecionou seus projetos existentes para a versão mais recente, mas o VS ainda cria novos projetos direcionados à v4.5 e, em seguida, faz referência a esses projetos mais antigos do novo projeto)

Reinstalar pacotes nuget fez o truque para mim. Depois de alterar as versões do .NET Framework para sincronizar todos os projetos, alguns dos pacotes de nuget (especialmente o Entity Framework) ainda estavam instalados para as versões anteriores. Este comando no Console do Gerenciador de Pacotes reinstala pacotes para toda a solução:

Update-Package –reinstall

Não sei por que isso funcionou, mas removi a referência do projeto que o VS2015 estava me dizendo que não conseguia encontrar e a adicionei novamente. Resolveu o problema. Eu tentei limpar, construir e reiniciar o VS sem sucesso.

Ao criar a solução, estava recebendo o mesmo erro (não foi possível encontrar o tipo ou espaço para nome ''). Abaixo dele , vi um aviso informando que "a referência não pôde ser resolvida" e para garantir "a montagem existe no disco".

Fiquei muito confuso, porque minha DLL estava muito claramente no local que a referência estava apontando. O VS não pareceu destacar nenhum erro até tentar construir a solução.

Finalmente percebi o problema (ou pelo menos o que suspeito ser o problema). Eu estava criando o arquivo da biblioteca na mesma solução. Portanto, mesmo que existisse no disco, estava sendo reconstruído naquele local (de alguma forma, no processo de reconstrução da biblioteca, meu outro projeto - na mesma solução - que referenciou a biblioteca deve ter decidido que a biblioteca não existia)

Quando cliquei com o botão direito do mouse no projeto e construí esse somente, em vez de toda a solução, não recebi o erro.

Para corrigir esse problema, adicionei a biblioteca como uma dependência ao projeto que a estava usando.

Para fazer isso:

1. Clique com o botão direito do mouse em minha solução no Solution Explorer e selecione "Properties"
2. Depois, em "Propriedades comuns", selecione "Dependências do projeto".
3. Em seguida, no menu suspenso Projetos, selecionei o projeto que contava com a biblioteca e
4. Marque a caixa ao lado da biblioteca encontrada em "Depende"

Isso garante que o projeto da biblioteca seja construído primeiro.

Primeiro, eu verificaria se as informações geradas do seu projeto não estão corrompidas. Faça uma limpeza e reconstrua sua solução.

Se isso não ajudar, uma coisa que vi no passado para problemas de designer é abrir um projeto de formulários do Windows e depois fechá-lo novamente. Este é um pouco de galinha-entranhas-ish, no entanto, por isso não prenda a respiração.

Uma situação mais complicada em que me deparei foi: o Projeto 1 tem como alvo a estrutura completa 4.0 com o Microsoft.Bcl.Asyncpacote instalado. O projeto dois tem como alvo a estrutura completa 4.0, mas não compila quando faz referência a uma classe do projeto uma.

Depois de instalar o pacote Async NuGet no segundo projeto, ele foi compilado corretamente.

No meu caso, acho que a referência no VisualStudio tem um triângulo e um ponto de exclamação como esta imagem,

em seguida, clique com o botão direito do mouse em removê-lo e adicione a referência da dll corretamente novamente, o problema foi resolvido.

Este funcionou para mim. Na sua classe, onde o nome da classe é definido, por exemplo: Classe pública ABC, remova um caractere e aguarde um pouco. Sua lista de erros aumentará porque você mudou o nome. Agora coloque de volta o caractere que você digitou. Isso funcionou para mim, espero que funcione para você também. Boa sorte!!!

Eu tive um problema semelhante: o compilador não conseguiu detectar uma pasta dentro do mesmo projeto , portanto, uma diretiva de uso vinculada a essa pasta gerou um erro. No meu caso, o problema se originou ao renomear a pasta . Embora eu tenha atualizado o espaço para nome de todas as classes nessa pasta, as informações do projeto não foram atualizadas. Eu tentei de tudo: excluir o arquivo .suo e as pastas bin e obj, limpar a solução, recarregar o projeto - nada ajudou. Resolvi o problema excluindo a pasta e as classes internas, criando uma nova pasta e criando novas classes nessa nova pasta (simplesmente mover as classes para dentro da nova pasta não ajudava).

PS: No meu caso, eu estava trabalhando em um aplicativo Web, mas esse problema pode ocorrer em diferentes tipos de projetos.

[Facepalm] Meu problema foi que eu adicionei a dependência na maneira C ++ de fazer as coisas.

Vá para o projeto que não será criado, abra a pasta 'Referências' no Gerenciador de Soluções e veja se sua dependência está listada.

Caso contrário, você pode 'Adicionar referência' e escolher a dependência na guia Projetos.

Crescimento Shankar.

Tivemos um caso estranho disso que eu consertei em uma solução. Havia um caractere oculto / espaço em branco na frente de uma instrução "using" no projeto principal. Esse projeto seria bom e o site funcionava bem, mas o projeto de teste de unidade que o referenciava não pôde ser construído.

Encontrei esse problema ao atualizar projetos existentes do VS2008 para o VS2012. Eu descobri que dois projetos (os únicos que eu criei) tinham como alvo diferentes .Net Frameworks (3.5 e 4.0). Resolvi isso na guia Aplicativo dos projetos, certificando-me de que os dois projetos tivessem ".NET Framework 4" na caixa Target Framework.

Tive os mesmos erros, minha história foi a seguinte: após uma má fusão (via git), um dos meus arquivos .csproj tinha compileentradas duplicadas, como:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

Se você tem uma solução grande e mais de 300 mensagens na janela de erros, é difícil detectar esse problema. Então, eu abri o arquivo .csproj danificado via bloco de notas e removi as entradas duplicadas. Trabalhou no meu caso.

Eu tive o mesmo problema discutido: o VS 2017 sublinha uma classe no projeto referenciado como erro, mas a solução cria ok e até o intellisense funciona.

Aqui está como eu consegui resolver este issu:

1. Descarregar o projeto referenciado
2. Abra o arquivo .proj no VS (eu estava procurando duplicatas, como alguém sugeriu aqui)
3. Recarregar projeto novamente (não alterei nem salvei o arquivo do proj, pois não havia duplicatas)

Você também pode tentar eliminar o código com o qual pensa estar tendo problemas e ver se ele é compilado sem referências a esse código. Caso contrário, corrija as coisas até que seja compilado novamente e, em seguida, retorne o código do problema suspeito . Às vezes, recebo erros estranhos sobre classes ou métodos que eu sei que estão corretos quando o compilador não gosta de outra coisa. Depois que eu conserto o que realmente está sendo desligado, esses erros "fantasmas" desaparecem.

Eu sei que isso está chutando um cavalo morto, mas eu tive esse erro e os quadros onde está bem. Meu problema era basicamente afirmar que uma interface não pôde ser encontrada, mas foi criada e acessada muito bem. Então comecei a pensar: "Por que apenas essa interface quando outras pessoas estão funcionando bem?"

Acabei acessando um serviço usando o WCF com uma interface de terminal que usava a Entidade versão 6 e o ​​restante dos projetos usando a versão 5. Em vez de usar o NuGet, simplesmente copiei os pacotes de nuget em um repositório local para reutilização e listados de forma diferente.

por exemplo, EntityFramework6.dll versus EntityFramework.dll .

Eu então adicionei as referências ao projeto do cliente e puf, meu erro foi embora. Sei que esse é um caso extremo, já que a maioria das pessoas não mistura versões do Entity Framework.

Adicionando minha solução à mistura porque era um pouco diferente e demorei um pouco para descobrir.

No meu caso, adicionei uma nova classe a um projeto, mas como minhas ligações de controle de versão não estavam definidas, eu precisava tornar o arquivo gravável fora do Visual Studio (via VC). Eu havia cancelado o salvamento no Visual Studio, mas depois que tornei o arquivo gravável fora do VS, pressionei Salvar tudo novamente no VS. Isso, inadvertidamente, fez com que o novo arquivo de classe não fosse salvo no projeto ... no entanto .. O Intellisense ainda o mostrava azul e válido nos projetos de referência, mesmo quando eu tentava recompilar o arquivo não foi encontrado e obteve o erro de tipo não encontrado. O fechamento e a abertura do Visual Studio ainda mostravam o problema (mas, se eu tivesse anotado, o arquivo da classe estava ausente ao reabrir).

Depois que percebi isso, a correção foi simples: com o arquivo do projeto definido como gravável, leia o arquivo ausente no projeto. Tudo cria bem agora.

Eu tive o mesmo problema. Uma noite, meu projeto compilaria na manhã seguinte ERROS!

Acabei descobrindo que o estúdio visual decidiu "ajustar" algumas das minhas referências e apontá-las para outro lugar. por exemplo:

System.ComponentModel.ISupportInitialize de alguma forma se tornou "blahblah.System.ComponentModel.ISupportInitialize"

Uma coisa rude para vs fazer se você como eu

O evento acontece no Visual Studio 2017.

1. Reinicie o Visual Studio
2. Projeto limpo que falha ao criar.
3. Reconstrua o projeto.

Meu caso foi o mesmo que discutido aqui, mas nada o resolveu até remover a System.Corereferência da lista de referências (tudo funcionou bem sem ele)

espero que ajude alguém, porque esse problema é bastante frustrante

Para resolver esse problema, também pode ajudar a excluir e recriar o *.sln.DotSettingsarquivo da solução associada.

No meu caso, eu tinha uma classe listada na pasta de origem apropriada, mas não estava registrando no Solution Explorer. Eu tive que clicar com o botão direito do mouse no projeto> Adicionar item existente e selecionar manualmente a classe que estava faltando. Então tudo funcionou bem!

No meu caso, o problema era que, depois de alterar o namespace para exatamente o mesmo que em outro projeto (intencionalmente), o nome do assembly também foi alterado pelo VS, portanto, havia dois assemblies com o mesmo nome, um substituindo o outro

No meu caso, eu tinha um arquivo criado por dependência externa (xsd2code) e, de alguma forma, seus arquivos designer.cs não foram processados ​​pelo VS corretamente. Criar um novo arquivo no Visual Studio e colar o código nele fizeram o truque para mim.

Para quem está recebendo esse erro ao tentar publicar seu site no Azure, nenhuma das soluções de aparência promissora acima me ajudou. Eu estava no mesmo barco - minha solução foi criada por conta própria. Acabei tendo que

1. Remova todos os pacotes de pepitas na minha solução.
2. Feche e reabra minha solução.
3. Adicione novamente todos os pacotes de nuget.

Um pouco doloroso, mas foi a única maneira de publicar meu site no Azure.

Eu recebi esse erro ao tentar criar uma compilação com uma compilação do Visual Studio Team Services em execução na minha máquina local como agente.

Funcionou muito bem no meu espaço de trabalho regular e eu consegui abrir o arquivo SLN dentro da pasta do agente localmente e tudo foi compilado corretamente.

A DLL em questão foi armazenada no projeto Lib/MyDLL.DLLe faz referência a ela no arquivo csproj:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

Acontece que, literalmente, simplesmente não estava encontrando o arquivo, apesar do caminho da dica. Eu acho que talvez o msbuild estivesse procurando em relação ao arquivo SLN em vez do arquivo do projeto.

De qualquer forma, se a mensagem Could not resolve this reference. Could not locate the assemblyrecebida for exibida, verifique se a DLL está em um local acessível para o msbuild.

Eu meio que trapacei e encontrei uma mensagem que dizia Considered "Reference\bin\xxx.dll"e apenas copiava as DLLs para lá.

No meu caso, adicionar a dll como referência deu o type or namespace name could not be founderro. No entanto, copiar e colar o arquivo dll diretamente na pasta bin resolveu o erro.

Não faço ideia por que isso funcionou.

Eu sei que esse encadeamento é antigo, mas, de qualquer maneira, estou compartilhando, tenho que instalar todas as dependências de terceiros do assembly importado - como o assembly importado não foi incluído como pacote Nuget, portanto, suas dependências estavam ausentes.

Hop this help :)

No meu caso, eu tinha dois projetos em uma solução, adicionei um subdomínio ao projeto referenciado, mas, ao criar, não percebi que a construção do projeto referenciado falhou e que usou a última versão criada com êxito, que não tenha esse novo espaço para nome, portanto, o erro estava correto e não pode ser encontrado, porque não existia. A solução era obviamente corrigir erros no projeto referenciado.

Eu estava trabalhando na edição da comunidade do VS 2017 e tive o mesmo problema com os pacotes de nuget do CefSharp.

Os pacotes foram baixados e restaurados com êxito, o projeto pode ser construído e executado com êxito - apenas a marcação indicava que os espaços para nome não eram reconhecidos.

Tudo o que eu precisava fazer era abrir a Referencesseção e clicar em um dos sinais amarelos de exclamação.

Após alguns segundos, os erros de marcação desapareceram.