我得到了：

type or namespace name could not be found

VS2010中的C WPF应用程序出错。这段代码编译得很好，但我突然发现了这个错误。我试图删除项目引用和using声明，关闭vs2010并重新启动，但我仍然有这个问题。

你知道为什么会发生这种情况吗？在这种情况下，我似乎在做正确的事情，重新引用&EDOCX1[0]声明？

我在VS2010中还注意到，该命名空间的IntelliSense工作正常，因此看起来VS2010具有项目引用，一方面看到了该命名空间，但在编译期间没有看到它？

这可能是两个项目之间.NET框架版本不兼容的结果。

它可以通过两种方式发生：

例如，当应用程序设置为针对.NET 4客户机配置文件框架，并且它引用的项目针对完整的.NET 4框架时，就会发生这种情况。

为了更清楚地说明这一点：

• 项目A以客户概要框架为目标
• 项目A参考项目B
• 项目B以整个框架为目标

在这种情况下，解决方案是升级应用程序的框架目标(项目A)，或者降级引用程序集的目标(项目B)。完整框架应用程序可以引用/使用客户端配置文件框架程序集，但不能反过来(客户端配置文件不能引用完整框架目标程序集)。

请注意，当您在VS2012或VS2013(使用.NET 4.5作为默认框架)中创建一个新项目时，也可能会出现此错误，并且：

• 引用项目使用.NET 4.0(当您从vs2010迁移到vs2012或vs2013，然后添加新项目时，这是很常见的)

• 引用的项目使用更高的版本，即4.5.1或4.5.3(您的目标是现有项目的最新版本，但vs仍然创建针对v4.5的新项目，然后您引用新项目中的旧项目)

重新安装Nuget软件包对我有好处。在我更改了所有项目的.NET框架版本以保持同步之后，一些nuget包(尤其是实体框架)仍然安装在以前的版本中。包管理器控制台中的此命令重新安装整个解决方案的包：

生成解决方案时，我遇到了相同的错误(找不到类型或命名空间"")。在它下面，我看到一条警告，指出"无法解析引用"，并确保"程序集存在于磁盘上"。

我很困惑，因为我的动态链接库非常清楚地位于引用所指向的位置。在我尝试构建解决方案之前，VS似乎没有突出显示任何错误。

我终于意识到了问题(至少我怀疑是问题)。我正在用同样的解决方案构建库文件。因此，即使它存在于磁盘上，它也在那个位置被重建(在图书馆重建的过程中，我的另一个项目——在同一个解决方案中——引用了图书馆——一定是图书馆决定了图书馆不存在)

当我右键单击这个项目并只构建它时，我没有得到错误，而是整个解决方案。

为了解决这个问题，我将库作为依赖项添加到了使用它的项目中。

这样做：

这样可以确保首先构建库项目。

我不知道这为什么有效，但我删除了VS2015告诉我找不到的项目引用，并再次添加了它。解决了问题。我试过清理，建造和重新启动vs，但都没用。

首先，我将验证您的项目生成的信息是否已损坏。清理并重新构建解决方案。

如果这不起作用，我以前看到的一件事就是打开一个Windows窗体项目，然后再次关闭它。不过，这是小鸡的内脏，所以不要屏住呼吸。

我遇到的更棘手的情况是：Project One的目标是安装了Microsoft.Bcl.Async包的4.0完整框架。项目2以4.0完整框架为目标，但在引用项目1类时不会编译。

一旦我在第二个项目上安装了AsyncNuget包，它就编译得很好。

这个对我有用。在类中，定义类名的地方，例如：公共类abc，删除一个字符并稍等。您的错误列表将增加，因为您更改了名称。现在放回您键入的字符。这对我很有用，希望对你也有用。祝你好运！！！！

我有一个类似的问题：编译器无法检测到同一个项目中的文件夹，因此一个指向该文件夹的using指令产生了一个错误。在我的例子中，问题源于重命名文件夹。尽管我更新了该文件夹中所有类的名称空间，但是项目信息不知何故未能更新。我尝试了所有的方法：删除.suo文件、bin和obj文件夹、清理解决方案、重新加载项目——没有任何帮助。我通过删除文件夹和其中的类、创建一个新文件夹并在该新文件夹中创建新类(只是将类移到新文件夹中没有帮助)来解决这个问题。

PS：在我的例子中，我正在开发一个Web应用程序，但是这个问题可能发生在不同类型的项目中。

在我的示例中，我发现VisualStudio中的引用有一个三角形和一个感叹号作为此图像，

我的问题是我在C++中增加了依赖性。

转到不生成的项目，在解决方案资源管理器中打开"引用"文件夹，然后查看是否列出了依赖项。

如果没有，可以"添加引用"并选择"项目"选项卡上的依赖项。

Boom Shankar。

我也遇到了同样的问题：vs 2017强调引用项目中的一个类是错误，但解决方案构建良好，甚至IntelliSense也可以工作。

以下是我如何解决这个问题：

我们有一个奇怪的案例，我刚刚在一个解决方案中解决了这个问题。在主项目中的"using"语句前面有一个隐藏/空白字符。那个项目可以很好地构建，网站也可以很好地工作，但是引用它的单元测试项目无法构建。

我在将现有项目从VS2008升级到VS2012时遇到了这个问题。我发现两个项目(我创建的唯一两个)针对不同的.NET框架(3.5和4.0)。我通过确保两个项目在目标框架框中都有".NET Framework 4"，在项目的"应用程序"选项卡上解决了这个问题。

我也有同样的问题。有一天晚上，我的项目会编译第二天早上的错误！.

我最终发现，Visual Studio决定"调整"一些引用，并将它们指向其他地方。例如：

system.componentmodel.isupportinitialize不知何故成为"blahblah.system.componentmodel.isupportinitialize"

如果你像我一样，对vs来说是一件很不礼貌的事情

我知道这是一派胡言，但我犯了这个错误，框架也很好。我的问题基本上是说找不到一个接口，但是它构建和访问都很好。所以我开始想："为什么只有这个界面，当其他人工作正常？"

最后，我使用WCF访问了一个服务，该服务带有一个端点的接口，该接口使用的是实体版本6，其余的项目使用的是版本5。我不使用nuget，而是简单地将nuget包复制到本地存储库以供重用，并以不同的方式列出它们。

例如，EntityFramework6.dll与EntityFramework.dll。

然后我添加了对客户机项目和poof的引用，我的错误就消失了。我意识到这是一个边缘案例，因为大多数人不会混合实体框架的版本。

在我的例子中，问题是在将名称空间更改为与另一个项目中完全相同的名称空间之后(故意)，程序集的名称也被vs更改了，因此有两个程序集具有相同的名称，一个程序集覆盖另一个程序集

您还可以尝试消除您认为有问题的代码，看看它是否编译时没有引用该代码。如果没有，修复问题直到它再次编译，然后将可疑的问题代码重新输入。有时，当编译器不喜欢其他东西时，我会得到一些关于类或方法的奇怪错误，我知道这些错误是正确的。一旦我修复了它真正挂断的东西，这些"幻影"错误就消失了。

将我的解决方案添加到混合物中，因为它有点不同，我花了一段时间才弄清楚。

在我的例子中，我向一个项目添加了一个新的类，但是由于没有设置版本控制绑定，我需要使文件在Visual Studio之外可写(通过VC)。我取消了在Visual Studio中保存，但在我使文件在vs外部可写之后，我又在vs中单击了"全部保存"。这无意中导致新类文件无法保存在项目中。但是..IntelliSense仍然在引用项目中显示为蓝色且有效，即使当我尝试重新编译文件时，该文件不在并得到类型未找到错误。关闭和打开Visual Studio仍然显示了问题(但如果我注意到重新打开时类文件丢失)。

一旦我意识到这一点，修复就很简单：将项目文件设置为可写，将丢失的文件读到项目中。现在一切都很好。

在我的例子中，有一个类列在适当的源文件夹中，但没有在解决方案资源管理器中注册。我必须右键单击项目>添加现有项，然后手动选择它所说的缺少的类。然后一切正常！

同样的错误，我的故事如下：在错误合并(通过git)之后，我的一个.csproj文件复制了compile项，如：

如果您有一个大的解决方案，并且错误窗口中有超过300条消息，那么很难检测到这个问题。所以我通过记事本打开了损坏的.csproj文件并删除了重复的条目。在我的案子里工作过。

IT事件发生在Visual Studio 2017中。

为了解决这个问题，还可以删除并重新创建相关解决方案的*.sln.DotSettings文件。

在我的例子中，我有一个由外部依赖项(xsd2code)构建的文件，但它的designer.cs文件却没有被vs正确处理。在Visual Studio中创建一个新文件并粘贴其中的代码，这对我有好处。

在我的例子中，我研究了解决方案属性，并确保在两个项目的配置中都签入了"build"。我的主要项目没有检查过。

尝试使用在本地计算机上作为代理运行的Visual Studio Team Services生成生成时出现此错误。

它在我的常规工作区中工作得很好，我可以在本地打开代理文件夹中的SLN文件，所有的编译都正常。

有问题的dll以Lib/MyDLL.DLL的形式存储在项目中，并在csproj文件中引用：

事实证明，尽管有提示路径，但实际上并没有找到文件。我认为msbuild可能是相对于sln文件而不是项目文件查找的。

在任何情况下，如果您得到的消息是Could not resolve this reference. Could not locate the assembly，那么请确保dll位于msbuild可访问的位置。

我有点作弊，发现了一条消息，上面写着Considered"Reference\bin\xxx.dll"，只是把dll复制到那里。

我的情况与这里讨论的情况相同，但在我从参考列表中删除System.Core参考之前，没有解决它(没有它，一切都正常工作)。

希望它能帮助别人，因为这个问题很令人沮丧

在我的例子中，添加dll作为引用会导致type or namespace name could not be found错误。但是，直接在bin文件夹中复制和粘贴dll文件解决了该错误。

不知道为什么会这样。

我知道这个线程很旧，但是不管怎样，我还是在共享，我必须安装导入程序集的所有第三部分依赖项-因为导入的程序集没有作为nuget包包含，因此它的依赖项丢失。

点击此帮助：)

在我的例子中，我在一个解决方案中有两个项目，我在引用的项目中添加了一个子名称空间，但是在生成时，我没有注意到引用的项目生成失败，它使用了最后一个成功生成的版本，而这个版本没有这个新名称空间，所以错误是正确的，无法找到它，因为它不存在解决方案显然是为了修复引用项目中的错误。

我正在研究vs 2017社区版，与Cefsharp Nuget软件包有相同的问题。

包已成功下载和还原，可以成功生成和运行Project-只有标记指示无法识别命名空间。

我所要做的就是打开References部分，点击其中一个黄色的感叹号。

几秒钟后，标记错误消失了。

对于任何一个在尝试将其网站发布到Azure时遇到此错误的人来说，上面那些有希望的解决方案都没有帮助我。我在同一条船上——我的解决方案本身就很好。我最终不得不

有点痛苦，但这是我能让我的网站发布到Azure的唯一方法。

从GAC中删除程序集(C:windowsassembly文件夹-选择您的assembly，右键单击并卸载)。因为解决方案使用guid保持引用，并且如果guid在gac中，它将继续使用gac版本进行编译。