“type or namespace name could not be found” 问题怎么解决

我得到如下错误:

type or namespace name could not be found

错误的c# WPF应用程序在VS2010。这部分代码编译得很好，但突然就出现了这个错误。我已经尝试删除项目引用和using语句，关闭VS2010并重新启动，但我仍然有这个问题。

任何想法，为什么这可能会发生，它似乎我在做正确的事情参考&using声明吗?

我还注意到在VS2010，智能感知的名称空间是工作的好，所以它似乎VS2010有项目引用，是看到名称空间在一方面，但在编译期间没有看到它?

459038 次浏览
小开

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

如果这还不起作用，我在过去看到的一种解决设计器问题的方法是打开一个windows窗体项目，然后再次关闭它。这有点像鸡内脏，所以别抱太大希望。

小开

你也可以尝试消除你认为有问题的代码，看看它是否在没有引用该代码的情况下编译。如果不是，修复问题直到它再次编译，然后把你的怀疑问题代码放回去。有时，当编译器不喜欢其他东西时，我就会得到一些我知道是正确的类或方法的奇怪错误。一旦我修复了它真正挂起来的东西，这些“幻影”错误就消失了。

小开
最佳答案

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

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

  1. 客户档案项目引用了一个完整的框架项目;或
  2. 一个针对新框架版本的旧框架版本

例如，当一个应用程序被设置为目标。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的新项目，然后你从新项目中引用这些旧项目)

小开

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

小开

我们有一个奇怪的例子，我刚刚在溶液中修正了它。在主项目中的“using”语句前有一个隐藏/空白字符。这个项目可以很好地构建，网站也可以很好地运行，但是引用它的单元测试项目不能被构建。

小开

这个方法对我很管用。在定义了类名的类中，例如:公共类ABC，删除一个字符并等待一会儿。您的错误列表将增加，因为您更改了名称。现在把输入的字符放回去。这对我有用，希望对你也有用。祝你好运! !

小开

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

小开

[Facepalm]我的问题是我在c++的做事方式中添加了依赖。

转到无法构建的项目，在解决方案资源管理器中打开“References”文件夹，查看是否列出了您的依赖项。

如果没有，您可以“添加引用”并在Projects选项卡上选择依赖项。

Shankar繁荣。

小开

在构建解决方案时，我得到了相同的错误(类型或名称空间' '找不到)。在它下面我看到一个警告声明“引用无法解析”并确保“程序集存在于磁盘上”。

我非常困惑，因为我的DLL非常清楚地位于引用所指向的位置。VS似乎没有突出显示任何错误，直到我尝试构建解决方案。

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

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

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

这样做:

    我在解决方案资源管理器中右键单击我的解决方案并选择 李“属性”< / >
  1. 然后在“Common Properties”中选择“Project Dependencies”。
    2. 然后在项目下拉菜单中，我选择了项目 依赖于库，而
  2. 选中“依赖”下的库旁边的复选框

这确保首先构建库项目。

小开

我在将现有项目从VS2008升级到VS2012时遇到了这个问题。我发现有两个项目(我只创建了两个)针对的是不同的. net框架(3.5和4.0)。我在项目的Application选项卡上解决了这个问题，确保两个项目都有“。NET Framework 4”中的目标框架。

小开
我遇到的一个更棘手的情况是: 项目一的目标是安装Microsoft.Bcl.Async包的4.0完整框架。 项目二的目标是4.0完整框架，但是当引用项目一的类时不会编译

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

小开

我知道这是踢死马，但我有这个错误和框架在哪里好。我的问题基本上是声明无法找到接口，但它构建和访问都很好。所以我开始思考:“为什么只有这个界面，而其他人都工作得很好?”

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

例如:EntityFramework6.dll vs . < em > EntityFramework.dll < / em >。

然后，我将引用添加到客户端项目，噗的一声，我的错误消失了。我意识到这是一个边缘情况，因为大多数人不会混合实体框架的版本。

小开

重新安装nuget包对我来说很有用。在我将. net Framework版本更改为与所有项目同步后，一些nuget包(特别是Entity Framework)仍然为以前的版本安装。这个命令在包管理器控制台中为整个解决方案重新安装包:

Update-Package –reinstall
小开

在我的案例中，我有一个由外部依赖(xsd2code)构建的文件，不知为何它的designer.cs文件没有被VS正确处理。在Visual Studio中创建一个新文件并将代码粘贴进去，这对我来说很管用。

小开

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

在我的情况下，我添加了一个新的类到一个项目，但因为我的版本控制绑定没有设置，我需要使文件可写的Visual Studio之外(通过VC)。我已经取消了在Visual Studio中的保存，但在我使文件在VS外部可写之后，我又在VS中单击save All，这无意中导致了新的类文件没有保存在项目中..然而。智能感知仍然显示为蓝色，在引用项目中有效，即使当我试图重新编译文件未找到并得到类型未找到错误。关闭和打开Visual Studio仍然显示问题(但如果我注意到重新打开时类文件丢失)。

当我意识到这一点时，解决方法很简单:将项目文件设置为可写，将丢失的文件读入项目。现在都建好了。

小开

对于那些在试图将网站发布到Azure时遇到这种错误的人来说，上面这些看起来很有希望的解决方案都没有帮助到我。我也在同一条船上——我的解决方案本身构建得很好。最后我不得不这么做

  1. 把我溶液里的鸡块都去掉。
  2. 关闭并重新打开我的溶液。
  3. 重新添加所有的nuget包。

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

小开

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

我最终发现visual studio决定“调整”我的一些参考，并将它们指向其他地方。例如:

system。componentmodel。isupportinitialize变成了blahblah。system。componentmodel。isupportinitialize

如果你和我一样，我这样做是很粗鲁的

小开

在我的例子中，我发现VisualStudio中的引用有一个三角形和一个感叹号，就像这个图像，

></a></p> <p>然后，我右键单击删除它，并正确地添加dll引用，问题就解决了。</p></div> </div> </div> </div> </div> <div class=

小开

我不知道为什么这样工作，但我删除了VS2015告诉我它找不到的项目引用，并再次添加它。解决了问题。我尝试过清理、构建和重新启动VS，但都无济于事。

小开

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

PS:以我为例，我正在开发一个web应用程序，但这个问题可能发生在不同类型的项目中。

小开

在我的例子中，我进入解决方案属性，并确保在两个项目的配置中选中了“Build”。我的主要项目没有检查。

enter image description here

小开
有同样的错误，我的故事如下: 在糟糕的合并(通过git)后，我的一个.csproj文件有重复的compile条目，如:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate
如果你有一个大的解决方案，在错误窗口中有超过300条消息，很难检测到这个问题。 所以我已经通过记事本打开了损坏的.csproj文件，并删除了重复的条目。

小开

我在试图以代理的身份在本地机器上运行Visual Studio Team Services构建时遇到此错误。

它在我的常规工作空间中工作得很好，我能够在本地代理文件夹中打开SLN文件，一切都编译好了。

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

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

结果是，尽管有提示路径，它还是找不到文件。我认为msbuild可能是相对于SLN文件而不是项目文件。

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

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

小开

它甚至发生在Visual Studio 2017中。

  1. 重启Visual Studio
  2. 无法构建的干净项目。
  3. 重新构建项目。
小开

我的情况与这里讨论的相同，但没有解决它，直到我从引用列表中删除System.Core引用(没有它一切工作都很好)

希望这能帮助到一些人，因为这个问题很令人沮丧

小开

我遇到了同样的问题:VS 2017强调引用项目中的一个类为错误，但解决方案构建正常，甚至智能感知工作。

下面是我解决这个问题的方法:

  1. 卸载引用的项目
  2. 在VS中打开。proj文件(我正在寻找重复的人建议在这里)
  3. 重新加载项目(我没有改变甚至保存proj文件，因为我没有任何副本)
小开

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

小开

我知道这个线程是旧的，但无论如何我共享，我必须安装导入程序集的所有第三方依赖项-因为导入的程序集不包括在Nuget包中，因此它的依赖项丢失了。

跳这个帮助:)

小开

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

小开

我当时正在做VS 2017社区版，CefSharp的金块包也有同样的问题。

包被成功下载并恢复，项目可以构建并成功运行-只是标记表明名称空间无法识别。

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

enter image description here

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

enter image description here

小开

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

小开
好吧，多年后使用VS 2017 . net Core 2.2 Razor Pages，我觉得这个答案可能会帮助到一些人。 如果是蛇，它会咬我的。 我到处乱扔东西，改变名称，重命名模型，突然我得到这个错误:

CS0246类型或命名空间名称“UploadFileModel”不存在

. find(是否缺少using指令或程序集引用?

这在我的。chstml Razor Page中用红色划线。(修正后未加下划线):

@page
@model UploadFileModel

所以，最后，幸运的是，我从其他人那里找到了我最初使用的代码，注意，名称空间不包括.cshtml文件名!!

这是我的坏假错误在命名空间的页面名称打我自己:

namespace OESAC.Pages.UploadFile
{
public class UploadFileModel : PageModel
{

我的原始代码所拥有的，我所要做的就是从命名空间UploadFile中删除页面名称:

namespace OESAC.Pages
{
public class UploadFileModel : PageModel
{
瞧，所有的错误都消失了!! 愚蠢的我。但是你知道，微软让。net c# MVC的东西让我们这些非计算机科学家非常困惑。我经常被鞋带绊倒，试图找出模型名称、页面名称和使用它们的语法。不应该这么难。哦。我希望错误和解决方案能帮助别人。错误是正确的，没有命名空间名为“UploadFileModel”哈哈
小开

从VS 2019企业版“降级”到VS 2019专业版后开始出现这个问题。 尽管错误显示在“错误”窗口中，但我可以毫无问题地构建项目。 尝试了这个线程和其他线程的许多解决方案，如均衡目标框架，删除并重新引用，删除.suo文件等。 对我来说，有效的方法是删除本地存储库中的项目，并从远程存储库中再次克隆它

小开

为此挣扎了一段时间，而且不是第一次了。在过去，这通常是配置不匹配造成的，但这次不是。

这一次，在我的应用程序中，自动生成绑定重定向被设置为true。

实际上，如果我在我的库中将其设置为true，那么我的库将在Microsoft.Reporting名称空间中获得此类型错误，如果我在应用程序中将其设置为true，那么我的应用程序将在我的库中获得此类型错误。

此外，对于我的库，该值默认为false，但对于我的应用程序，该值默认为true。因此，如果我不指定任何一个，我的库构建正常，但我的应用程序得到了我的库的错误。所以，我必须在我的应用程序中明确地将它设置为false，否则我将得到这个错误，没有说明原因。

我还发现，如果一个项目没有使用sdk csproj，我会得到这个消息不管环境如何。一旦我转换到sdk csproj，设置就会有所不同。

而且，在我的例子中，这一切似乎都与我的根库中的Microsoft.ReportingServices.ReportViewerControl.Winforms nuget包有关。

小开

我知道这是老问题了，但我也发现了同样的问题。我的项目建立，然后我更新Visual Studio到最新&该项目无法构建，因为它无法从单独的程序集找到类型定义。另一个程序集构建OK，主项目正确引用了它&自从它建成以来，什么都没有改变。

我清洗了整个溶液&重建它，它失败了。我自己做了这个组件，它做得很好。这个工程没有建成。我打扫&做了很多次，都失败了。然后我叫了一个同事去看，当我在他的监视下建造时，一切都建好了。

我认为Visual Studio工具是问题所在，特别是我刚刚更新了它。

小开
在将一些新代码合并到vs2019项目后遇到了同样的问题。 重新启动VS，卸载和重新加载项目，确保解决方案中的所有项目都具有相同的ToolsVersion=和TargetFrameworkVersion。

我有一个项目基板的情况，未能找到名称空间皮肤(在项目皮肤)。

最后我打开了基板。并检查了所有ProjectReference Include项。其他的都在那里，但没有对Skin的引用，即使Skin确实显示在小项目依赖对话框的复选框中。因此，项目依赖关系对话框接受了皮肤的复选框(并将其保存在某个地方)，但没有改变basis .csproj。然后，我手动添加了ProjectReference Include，以确保我拥有皮肤项目的正确路径和GUID。

<ProjectReference Include="..\Skin\Skin.csproj">
<Project>{1ad4b5d7-5014-4f5f-983e-2c59ac0e0028}</Project>
<Name>Skin</Name>
</ProjectReference>

然后我保存了基板。Csproj，问题就解决了。正如其他人所说，这是VS工具的一个问题

小开

检查包含缺失类型的.cs文件的建立行动。确保它是c#编译器。

  1. 单击包含缺失类型的.cs文件。
  2. 按F4调出属性。
  3. 确保建立行动被设置为c#编译器。

之前:

构建动作设置为 < / >

后:

一个c#文件的属性，其构建动作设置为 < / >

小开

我得到了这个错误“使用系统”;在我的VS2019解决方案中添加了一个新的库项目后。添加包Newtonsoft. json (currentversion)到库项目修复了这个问题，因为对Newtonsoft的依赖。Json包含了NETStandard。库的依赖项下的库，并正在生成一个警告图标。主项目有一个错误，直到我安装了Newtonsoft。Json，所以我认为它也适用于库;它确实做到了。

小开

在我的情况下，我卸载项目，然后:

  1. 打开myProject.csproj并将ToolsVersion="4.0"更新为ToolsVersion="12.0"(我使用vs 2017)(使用保卢斯的答案https://stackoverflow.com/a/64552201/1594487)。

  2. 从myProject.csproj中删除以下行:

    <Import Project="..\packages\EntityFramework.6.4.0\build\EntityFramework.props" Condition="Exists('..\packages\EntityFramework.6.4.0\build\EntityFramework.props')" />
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />

问题解决了。

小开

我在项目资源管理器中打开项目下面的引用，将鼠标悬停在其中一个缺失的引用上，很快，它就找到了所有东西。然后我就可以成功地建造了。

运行Visual Studio Community 2019，版本16.8.4

小开

确保您引用的是为项目/文件提供的名称空间。我的问题是，我从另一个项目复制了一个文件，忘记更改名称空间。

小开

当我尝试在云端构建我的项目时，我遇到了这个问题。它在我的本地设备上构建得很好，但在Gitlab CI/CD管道上却不行。

首先要做的是检查你是否上传/推送了所有需要的文件。在我的例子中，我的.gitignore文件配置错误，它忽略了重要的*。元文件。

修复。gitignore并再次推动，使项目在云中等同于我的本地版本，问题解决了。

小开
当我遇到上述错误时，我发现了一个非常简单的解决方案: 在控制台，我只是运行

dotnet build

之后，Visual Studio中的所有错误消息都消失了。

小开

检查你的文件扩展名:

工作在vscode和一直得到相同的错误，但一切工作!彩色编码，智能感知，快速操作，文件夹图标....但出于某种原因，它就是建不起来。

最后浏览本地文件系统，注意到类文件上的文件扩展名丢失了，构建一直抱怨这个问题。


提交答案