Obtendo “nome do tipo ou namespace não pôde ser encontrado”, mas tudo parece ok?

Estou recebendo um:

tipo ou nome do namespace não foi encontrado

erro para um aplicativo C # WPF no VS2010. Esta área de código estava compilando bem, mas de repente eu estou recebendo este erro. Eu tentei remover o Project Reference e a instrução using , fechando o VS2010 e reiniciando, mas ainda tenho esse problema.

Alguma idéia por que isso pode estar ocorrendo, onde parece que estou fazendo a coisa de escrever?

Eu também notei no VS2010 que o intellisense para esse namespace está funcionando ok, então parece que o VS2010 tem a referência do projeto e vê o namespace por um lado, mas durante a compilation não o vê?

Isso pode ser o resultado de uma incompatibilidade de versão do framework .NET entre dois projetos.

Isso pode acontecer de duas maneiras:

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

Por exemplo, isso acontecerá quando um aplicativo for configurado para atingir a estrutura de perfil de cliente do .net 4 e o projeto que ele referencia atingir a estrutura completa .Net 4.

Então, para tornar isso mais claro:

  • O projeto A tem como alvo a estrutura do perfil do cliente
  • Projeto A faz referência ao Projeto B
  • O projeto B visa o framework completo

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

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ê migra do VS2010 para o VS2012 ou VS2013 e depois adiciona um novo projeto)

  • os projetos referenciados usam uma versão maior, por exemplo, 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 visando a v4.5 e, em seguida, você faz referência a esses projetos mais antigos a partir do novo projeto)

Ao construir a solução, eu estava recebendo o mesmo erro (tipo ou namespace ” não pôde ser encontrado). Abaixo, vi um aviso dizendo que “a referência não pôde ser resolvida” e para ter certeza de que “a assembly existe em disco”.

Eu estava muito confuso, porque minha DLL estava muito claramente no local que a referência estava apontando. VS não parece destacar nenhum erro, até que eu tentei construir a solução.

Eu finalmente percebi o problema (ou pelo menos o que eu suspeito que era o problema). Eu estava construindo o arquivo da biblioteca na mesma solução. Então, mesmo existindo no disco, ele estava sendo reconstruído naquele local (de alguma forma, no processo da biblioteca sendo reconstruída meu outro projeto – na mesma solução – que referenciava a biblioteca deve ter decidido que a biblioteca não existia)

Quando cliquei com o botão direito no projeto e criei apenas isso, em vez da solução inteira, não obtive o erro.

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

Para fazer isso:

  1. Cliquei com o botão direito na minha solução no Solution Explorer e selecionei “Properties”
  2. Em seguida, em “Propriedades Comuns”, selecionei “Dependências do Projeto”.
  3. Em seguida, no menu suspenso Projetos, selecionei o projeto que dependia da biblioteca e
  4. Marquei a checkbox ao lado da biblioteca encontrada em “Depende de”

Isso garante que o projeto da biblioteca seja criado primeiro.

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

 Update-Package –reinstall 

Eu não tenho idéia do porque isso funcionou, mas eu removi a referência do projeto que o VS2015 estava me dizendo que não poderia encontrar, e adicionei novamente. Resolveu o problema. Eu tentei limpar, construir e reiniciar o VS sem sucesso.

Primeiro, gostaria de verificar se as informações geradas pelo 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. Isso é um pouco de entranhas de frango, mas não prenda a respiração.

Uma situação mais complicada que encontrei foi: O projeto um está direcionado à estrutura 4.0 completa com Microsoft.Bcl.Async pacote Microsoft.Bcl.Async instalado. O projeto dois visa a estrutura completa 4.0, mas não compilará quando fizer referência a uma class do Projeto um.

Depois de instalar o pacote Async NuGet no segundo projeto, ele compilou bem.

Este trabalhou para mim. Em sua class, onde o nome da class é definido, por exemplo: Classe pública ABC, remova um caractere e aguarde um pouco. Sua lista de erros aumentará porque você alterou 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 pôde detectar uma pasta dentro do mesmo projeto , portanto, uma diretiva usando vinculação a essa pasta gerou um erro. No meu caso, o problema se originou de renomear a pasta . Embora eu tenha atualizado o namespace de todas as classs dentro dessa pasta, as informações do projeto não conseguiram atualizar. 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 classs internas, criando uma nova pasta e criando novas classs nessa nova pasta (simplesmente mover as classs dentro da nova pasta não ajudou).

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

Eu encontrei este problema ao atualizar projetos existentes do VS2008 para o VS2012. Descobri que dois projetos (os dois únicos que 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 checkbox Target Framework.

Você também pode tentar eliminar o código com o qual acha que está tendo problemas e ver se ele é compilado sem referências a esse código. Se não, corrija as coisas até compilar novamente e depois volte a trabalhar com o seu código de problema suspeito . Às vezes, recebo erros estranhos sobre classs ou methods que sei que estão corretos quando o compilador não gosta de outra coisa. Depois de consertar a coisa que realmente está sendo travada, esses erros “fantasmas” desaparecem.

Nós tivemos um caso estranho disso que eu acabei de corrigir em uma solução. Havia um caractere oculto / em branco na frente de uma instrução “using” no projeto principal. Esse projeto iria construir bem e o site funcionou bem, mas o projeto de teste de unidade que fez referência a ele não pôde ser construído.

[Facepalm] Meu problema é que eu adicionei a dependência do jeito C ++ de fazer as coisas.

Vá para o projeto que não será compilado, abra a pasta ‘References’ no Solution Explorer e veja se sua dependência está listada.

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

Boom Shankar.

No meu caso, o problema foi que depois de alterar o namespace exatamente igual ao outro projeto (intencionalmente), o nome do assembly também foi alterado pelo VS, então havia dois assemblies com o mesmo nome, um substituindo o outro.

Eu sei que isso está chutando um cavalo morto, mas eu tive esse erro e os frameworks onde tudo bem. Meu problema era basicamente declarar que uma interface não pode ser encontrada, mas ela é construída e acessada muito bem. Então comecei a pensar: “Por que apenas essa interface quando os outros estão funcionando bem?”

Acabou que eu estava realmente acessando um serviço usando o WCF com uma interface de endpoint que estava usando Entity Version 6 e o ​​resto dos projetos estavam usando a versão 5. Em vez de usar o NuGet, simplesmente copiei os pacotes nuget para um repository local para reutilização e listou-os de forma diferente.

Por exemplo, EntityFramework6.dll versus EntityFramework.dll .

Eu adicionei as referências ao projeto do cliente e poof, meu erro foi embora. Eu percebo que este é um caso extremo, pois a maioria das pessoas não irá misturar versões do Entity Framework.

Adicionando a minha solução ao mix porque foi um pouco diferente e demorei um pouco para descobrir.

No meu caso, adicionei uma nova class a um projeto, mas como minhas ligações de version control não estavam definidas, precisei tornar o arquivo gravável fora do Visual Studio (via VC). Eu tinha cancelado o salvamento no Visual Studio, mas depois que fiz o arquivo gravável fora do VS, pressione Salvar tudo novamente no VS. Isso inadvertidamente fez com que o novo arquivo de class não fosse salvo no projeto.. .However..Intellisense ainda mostrou-o como azul e válido nos projetos de referência, embora quando eu tentei recompilar o arquivo não foi encontrado e tenho o tipo não encontrado erro. Fechar e abrir o Visual Studio ainda mostrou o problema (mas se eu tivesse tomado nota do arquivo de class estava faltando na reabertura).

Depois que percebi isso, a correção era simples: com o arquivo de projeto definido como gravável, leiai o arquivo que faltava para o projeto. Tudo se encheckbox bem agora.

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

então, eu clique com o botão direito do mouse para removê-lo e adicionar a referência dll corretamente novamente, o problema foi resolvido.

Tive os mesmos erros, minha história foi a seguinte: depois de uma fusão ruim (via git) um dos meus arquivos .csproj tinha inputs de compile duplicadas como:

    //it's a duplicate 

Se você tiver uma solução grande e mais de 300 mensagens na janela de erros, será difícil detectar esse problema. Então, eu abri o arquivo .csproj danificado por meio do bloco de notas e removi as inputs duplicadas. Trabalhei no meu caso.

O evento acontece no Visual Studio 2017.

  1. Reinicie o Visual Studio
  2. Projeto limpo que não consegue construir.
  3. Recrie o projeto.

Eu tive o mesmo problema discutido: VS 2017 sublinha uma class no projeto referenciado como erro mas a solução constrói 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 por duplicatas como alguém sugeriu aqui)
  3. Recarregue o projeto novamente (eu não mudei nem salvei o arquivo proj como não tinha duplicatas)

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

Para qualquer um que esteja recebendo esse erro quando tentar publicar seu site no Azure, nenhuma das soluções promissoras acima mencionadas me ajudou. Eu estava no mesmo barco – minha solução foi construída sozinha. Acabei tendo que

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

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

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

Eu finalmente descobri que o visual studio decidiu “tweak” algumas das minhas referências e apontá-los em outro lugar. por exemplo:

System.ComponentModel.ISupportInitialize de alguma forma se tornou “blahblah.System.ComponentModel.ISupportInitialize”

Uma coisa muito rude para o vs fazer se você como eu

Eu tenho esse erro tentando fazer uma compilation com uma compilation do Visual Studio Team Services em execução na minha máquina local como um agente.

Ele funcionou no meu espaço de trabalho regular muito bem e eu era capaz de abrir o arquivo SLN dentro da pasta do agente localmente e tudo compilado ok.

A DLL em questão foi armazenada no projeto como Lib/MyDLL.DLL e referências a isso no arquivo csproj:

  False Lib\MYDLL.dll  

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

Em qualquer caso, se a mensagem que você recebe é Could not resolve this reference. Could not locate the assembly Could not resolve this reference. Could not locate the assembly seguida, verifique se a DLL está em um local acessível para msbuild.

Eu meio que enganei e encontrei uma mensagem que dizia Considered "Reference\bin\xxx.dll" e apenas copiei as dlls para lá.

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

espero que ajude alguém porque esta questão é bastante frustrante

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

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

Não sei por que isso funcionou.

Eu sei que esta discussão é antiga, mas de qualquer maneira eu estou compartilhando, eu tenho que instalar todas as dependencies de terceira parte do assembly importado – como o assembly importado não foi incluído como pacote Nuget, portanto, suas dependencies estavam faltando.

Hop esta ajuda 🙂

No meu caso, eu tinha dois projetos em uma solução, adicionei um subespaço de nomes ao projeto referenciado, mas ao criar, não percebi que a construção referenciada do projeto falhou e usei a última versão criada com sucesso, o que não aconteceu tem esse novo namespace, então o erro estava correto, que não pode ser encontrado, porque ele não existia A solução era obviamente para corrigir erros no projeto referenciado.

No meu caso, entrei nas propriedades da solução e verifiquei se a opção “Build” estava marcada na configuração de ambos os projetos. Meu projeto principal não foi verificado.

insira a descrição da imagem aqui

Remova o conjunto da pasta GAC ​​(C: \ WINDOWS \ assembly – selecione seu assebly e clique com o botão direito e desinstale). porque a solução mantém a referência usando o guid e se essa orientação estiver no GAC, ela continuará usando a versão do GAC para compilation.