我得到一个:
找不到类型或命名空间名称
VS2010 中的 C# WPF 应用程序出错。这部分代码编译得很好,但突然我得到了这个错误。我试过删除项目参考和using
声明,关闭 VS2010 并重新启动,但我仍然有这个问题。
任何想法为什么会发生这种情况,似乎我在做正确的事情参考和using
声明?
我还在 VS2010 中注意到该命名空间的智能感知工作正常,所以看起来 VS2010 有项目引用并且一方面可以看到命名空间,但在编译期间看不到它?
我得到一个:
找不到类型或命名空间名称
VS2010 中的 C# WPF 应用程序出错。这部分代码编译得很好,但突然我得到了这个错误。我试过删除项目参考和using
声明,关闭 VS2010 并重新启动,但我仍然有这个问题。
任何想法为什么会发生这种情况,似乎我在做正确的事情参考和using
声明?
我还在 VS2010 中注意到该命名空间的智能感知工作正常,所以看起来 VS2010 有项目引用并且一方面可以看到命名空间,但在编译期间看不到它?
这可能是两个项目之间 .Net 框架版本不兼容的结果。
它可以通过两种方式发生:
例如,当应用程序设置为针对 .Net 4 Client Profile 框架,并且它引用的项目针对完整的 .Net 4 框架时,就会发生这种情况。
所以为了更清楚:
这种情况下的解决方案是升级应用程序的框架目标(项目 A),或者降级引用程序集的目标(项目 B)。完整的框架应用程序可以引用/使用客户端配置文件框架程序集,但反之则不行(客户端配置文件不能引用完整的框架目标程序集)。
请注意,当您在 VS2012 或 VS2013(使用 .Net 4.5 作为默认框架)中创建新项目时,您也可能会收到此错误,并且:
引用项目使用 .Net 4.0(这在您从 VS2010 迁移到 VS2012 或 VS2013 然后添加新项目时很常见)
引用的项目使用更高版本,即 4.5.1 或 4.5.3(您已将现有项目重新定位到最新版本,但 VS 仍会创建针对 v4.5 的新项目,然后您从新项目)
重新安装 nuget 包对我有用。在我将 .NET Framework 版本更改为与所有项目同步后,仍然为以前的版本安装了一些 nuget 包(尤其是 Entity Framework)。Packages Manager Console 中的此命令会重新安装整个解决方案的软件包:
Update-Package –reinstall
我不知道为什么会这样,但是我删除了 VS2015 告诉我它找不到的项目引用,并再次添加了它。解决了这个问题。我尝试过清理、构建和重新启动 VS 均无济于事。
在构建解决方案时,我遇到了同样的错误(找不到类型或命名空间“”)。在它下面我看到一条警告,指出“无法解析引用”并确保“程序集存在于磁盘上”。
我很困惑,因为我的 DLL 非常清楚地位于引用指向的位置。VS 似乎没有突出任何错误,直到我尝试构建解决方案。
我终于意识到了这个问题(或者至少我怀疑是这个问题)。我在同一个解决方案中构建库文件。因此,即使它存在于磁盘上,它也会在该位置重建(不知何故,在重建库的过程中,我的另一个项目 - 在同一个解决方案中 - 引用了该库必须确定该库不存在)
当我右键单击该项目并仅构建它而不是整个解决方案时,我没有收到错误消息。
为了解决这个问题,我将该库作为依赖项添加到正在使用它的项目中。
去做这个:
这可确保首先构建库项目。
首先,我将验证您的项目生成的信息没有损坏。对您的解决方案进行清理和重建。
如果这没有帮助,我在过去看到设计器问题的一件事是打开一个 Windows 窗体项目,然后再次关闭它。不过,这有点鸡内脏,所以不要屏住呼吸。
我遇到的一个更棘手的情况是:项目一的目标是Microsoft.Bcl.Async
安装了包的 4.0 完整框架。项目二以 4.0 完整框架为目标,但在引用项目一类时无法编译。
一旦我在第二个项目上安装了 Async NuGet 包,它就编译得很好。
我有一个类似的问题:编译器无法检测到同一个项目中的文件夹,因此链接到该文件夹的 using 指令产生了错误。就我而言,问题源于重命名文件夹。即使我更新了该文件夹中所有类的命名空间,项目信息也无法更新。我尝试了一切:删除 .suo 文件以及 bin 和 obj 文件夹,清理解决方案,重新加载项目 - 没有任何帮助。我通过删除文件夹和其中的类、创建一个新文件夹并在该新文件夹中创建新类来解决问题(只是在新文件夹中移动类没有帮助)。
PS:就我而言,我正在开发一个 Web 应用程序,但这个问题可能会出现在不同类型的项目中。
这个对我有用。在您的班级中,定义了班级名称,例如:公共班级 ABC,删除一个字符并稍等。您的错误列表将增加,因为您更改了名称。现在放回您输入的字符。这对我有用,希望它也对你有用。祝你好运!!!
[Facepalm] 我的问题是我在 C++ 做事方式中添加了依赖项。
转到不会构建的项目,在解决方案资源管理器中打开“参考”文件夹,查看是否列出了您的依赖项。
如果没有,您可以“添加参考”并在“项目”选项卡上选择依赖项。
轰香卡。
它甚至发生在 Visual Studio 2017 中。
我遇到了与讨论相同的问题:VS 2017 将引用项目中的一个类强调为错误,但解决方案构建正常,甚至智能感知工作。
这是我设法解决此问题的方法:
我们有一个奇怪的案例,我刚刚在一个解决方案中解决了这个问题。主项目中的“使用”语句前面有一个隐藏/空白字符。该项目将构建良好,网站运行良好,但无法构建引用它的单元测试项目。
我在将现有项目从 VS2008 升级到 VS2012 时遇到了这个问题。我发现两个项目(我创建的唯一两个)针对不同的 .Net 框架(3.5 和 4.0)。我在项目的应用程序选项卡上解决了这个问题,确保两个项目的目标框架框中都有“.NET Framework 4”。
有同样的错误,我的故事如下:在错误合并(通过 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 更新到最新版本,并且该项目无法构建,因为它无法从单独的程序集中找到类型定义。另一个程序集构建正常,主项目正确引用了它,并且自构建正常以来没有任何变化。
我清理了整个解决方案并重建了它,但它失败了。我自己构建了程序集,它构建好了。该项目没有建立。我多次清洁和建造,但都失败了。然后我打电话给同事看,当我和他一起看时,一切都建好了。
我认为 Visual Studio 工具是问题所在,尤其是当我刚刚更新它时。
您也可以尝试删除您认为有问题的代码,并查看它是否在没有引用该代码的情况下编译。如果不是,请修复问题,直到它再次编译,然后重新处理您怀疑的问题代码。有时,当编译器不喜欢其他东西时,我会收到关于我知道是正确的类或方法的奇怪错误。一旦我修复了它真正挂断的东西,这些“幻影”错误就会消失。
在我的情况下,问题是在将命名空间更改为与另一个项目中的完全相同之后(故意),程序集的名称也被 VS 更改了,所以有两个同名的程序集,一个覆盖另一个
我知道这是在踢死马,但我遇到了这个错误并且框架很好。我的问题基本上是说找不到接口,但它可以正常构建和访问。所以我开始思考:“为什么在其他人工作正常的情况下只有这个界面?”
最后,我实际上是使用 WCF 访问服务,其端点接口使用的是实体版本 6,而其余项目使用的是版本 5。我没有使用 NuGet,而是将 nuget 包复制到本地存储库以供重用和以不同的方式列出它们。
例如EntityFramework6.dll与EntityFramework.dll。
然后我添加了对客户端项目的引用,然后我的错误就消失了。我意识到这是一个边缘案例,因为大多数人不会混合使用实体框架的版本。
将我的解决方案添加到混合中,因为它有点不同,我花了一段时间才弄清楚。
在我的情况下,我向一个项目添加了一个新类,但由于没有设置我的版本控制绑定,我需要使文件在 Visual Studio 之外可写(通过 VC)。我已经取消了 Visual Studio 中的保存,但是在我使文件在 VS 之外可写之后,我在 VS 中再次点击 Save All。这无意中导致新的类文件没有保存在项目中..但是..Intellisense 仍然显示为蓝色并且在引用项目中有效,即使当我尝试重新编译该文件时没有找到并得到类型未找到错误。关闭和打开 Visual Studio 仍然显示问题(但如果我注意到重新打开时类文件丢失)。
一旦我意识到这一点,修复很简单:将项目文件设置为可写,将丢失的文件读取到项目中。现在一切都很好。
我遇到过同样的问题。一天晚上,我的项目将在第二天早上编译错误!。
我最终发现 Visual Studio 决定“调整”我的一些参考资料并将它们指向其他地方。例如:
System.ComponentModel.ISupportInitialize 不知何故变成了“blahblah.System.ComponentModel.ISupportInitialize”
如果你和我一样,vs 这样做是一件很不礼貌的事情
我的情况与此处讨论的相同,但在我System.Core
从参考列表中删除参考之前没有任何解决方案(没有它一切正常)
希望它会帮助某人,因为这个问题非常令人沮丧
为了解决这个问题,它还可以帮助删除和重新创建*.sln.DotSettings
相关解决方案的文件。
好的,多年后使用 VS 2017 .NET Core 2.2 Razor Pages 我觉得这个答案可能对某人有所帮助。如果它是一条蛇,它会咬我。我到处乱扔东西,更改名称,重命名模型,突然间我收到了这个错误:
错误 CS0246 找不到类型或命名空间名称“UploadFileModel”(您是否缺少 using 指令或程序集引用?)
这在我的 .chstml Razor 页面中用红色下划线。(修复后没有下划线):
@page
@model UploadFileModel
所以,最后,幸运的是,我从其他人那里找到了我最初使用的代码,并且瞧,命名空间不包含 .cshtml 文件名!!!
这是我在命名空间中使用页面名称的错误虚拟错误:
namespace OESAC.Pages.UploadFile
{
public class UploadFileModel : PageModel
{
我的原始代码所拥有的,我所要做的就是从命名空间 UploadFile 中删除页面名称:
namespace OESAC.Pages
{
public class UploadFileModel : PageModel
{
低头看,所有的错误都消失了!!傻我。但是你知道,MS 让我们这些非计算机科学家感到非常困惑的 .NET C# MVC 东西。我经常在鞋带上绊倒,试图找出型号名称、页面名称和使用它们的语法。不应该这么难。那好吧。我希望错误和解决方案可以帮助某人。错误是对的,没有名为“UploadFileModel”的命名空间哈哈。
将一些新代码合并到 vs2019 项目后遇到了同样的问题。重新启动 VS,卸载和重新加载项目,确保解决方案中的所有项目都具有相同的ToolsVersion=
和TargetFrameworkVersion
. 这些都没有帮助。
我有一个项目 Substrate 的案例,未能找到命名空间 Skin(在项目 Skin 中)。
最后我打开 Substrate.csproj 并检查了所有ProjectReference Include
条目。其他人都在那里,但没有提到皮肤,即使皮肤确实出现在小项目依赖关系对话框的复选框中。所以项目依赖对话框选择了 Skin 的复选框(并将其保存在某处),但没有改变 Substrate.csproj。然后我ProjectReference Include
手动添加,确保我有皮肤项目的正确路径和 GUID。
<ProjectReference Include="..\Skin\Skin.csproj"> <Project>{1ad4b5d7-5014-4f5f-983e-2c59ac0e0028}</Project> <Name>Skin</Name> </ProjectReference>
然后我保存了 Substrate.csproj,问题就解决了。所以正如其他人所说,这是VS工具的问题
就我而言,我卸载项目,然后:
打开myProject.csproj
并更新ToolsVersion="4.0"
到ToolsVersion="12.0"
(我正在使用 vs 2017)(使用Paulus的答案https://stackoverflow.com/a/64552201/1594487)。
从 中删除以下行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')" />
问题解决了。
在我的情况下,我有一个由外部依赖项(xsd2code)构建的文件,并且不知何故它的 Designer.cs 文件没有被 VS 正确处理。在 Visual Studio 中创建一个新文件并将代码粘贴到其中对我来说是诀窍。
对于尝试将网站发布到 Azure 时遇到此错误的任何人,以上看起来很有希望的解决方案都没有帮助我。我在同一条船上 - 我的解决方案本身就很好。我最终不得不
有点痛苦,但这是我可以让我的网站发布到 Azure 的唯一方法。
我在尝试使用在我的本地计算机上作为代理运行的 Visual Studio Team Services 构建进行构建时遇到此错误。
它在我的常规工作区中工作得很好,我能够在本地打开代理文件夹中的 SLN 文件,一切编译正常。
有问题的 DLL 存储在项目中,Lib/MyDLL.DLL
并在 csproj 文件中引用它:
<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复制到那里。
就我而言,添加 dll 作为参考会导致type or namespace name could not be found
错误。但是,直接在 bin 文件夹中复制和粘贴 dll 文件解决了该错误。
不知道为什么会这样。
我知道这个线程很旧,但无论如何我要分享,我必须安装导入程序集的所有第三方依赖项 - 因为导入的程序集没有包含在 Nuget 包中,因此它的依赖项丢失了。
跳这个帮助:)
在我的情况下,我在一个解决方案中有两个项目,我在引用的项目中添加了一个子命名空间,但是在构建时,我没有注意到引用的项目构建失败并且它使用了最后一个成功构建的版本,它没有有这个新的命名空间,所以错误是正确的,找不到它,因为它不存在解决方案显然是修复引用项目中的错误。
从 VS 2019 Enterprise“降级”到 VS 2019 Professional 后开始出现此问题。虽然错误显示在错误窗口中,但我可以毫无问题地构建项目。从这个线程和其他解决方案尝试了许多解决方案,如均衡目标框架、删除并再次引用、删除 .suo 文件等。对我有用的只是删除本地存储库中的项目并从远程存储库再次克隆它。
挣扎了一段时间,不是第一次。在过去,它通常是配置不匹配,但这次不是。
这次事实证明,true
我的应用程序中设置了自动生成绑定重定向。
事实上,如果我true
在我的库中将其设置为,那么我的库会为Microsoft.Reporting
命名空间中的类型收到此错误,如果我true
在我的应用程序中将其设置为,那么我的应用程序会收到我的库中类型的此错误。
false
此外,对于我的库,该值似乎默认为,但true
对于我的应用程序。因此,如果我没有指定任何一个,我的库构建得很好,但我的应用程序会收到我的库的错误。所以,我必须false
在我的应用程序中专门设置它,否则我会得到这个错误,但没有说明原因。
我还发现,如果项目未使用 sdk csproj,无论设置如何,我都会收到此消息。一旦我转换为 sdk csproj,设置就会有所不同。
此外,就我而言,这一切似乎都与Microsoft.ReportingServices.ReportViewerControl.Winforms
我的根库中的 nuget 包有关。
我因“使用系统”而收到此错误;将新库项目添加到我的 VS2019 解决方案后。将包 Newtonsoft.Json(currentversion) 添加到库项目解决了该问题,因为 Newtonsoft.Json 的依赖项包括库的依赖项下的 NETStandard.Library 并产生警告图标。在我安装 Newtonsoft.Json 之前,主项目有一个错误,所以我认为它也适用于库;确实如此。
我在项目资源管理器中打开了项目下方的引用,将鼠标悬停在其中一个丢失的引用上,然后很快,它找到了所有内容。然后我能够成功构建。
运行 Visual Studio Community 2019,版本 16.8.4
确保您指的是为项目/文件提供的命名空间。我的问题是我从另一个项目中复制了一个文件并忘记更改命名空间。
我在尝试在云中构建我的项目时遇到了这个问题。它在我的本地设备上构建良好,但在 Gitlab CI/CD 管道上却不行。
首先要做的是检查您是否正在上传/推送所有需要的文件。就我而言,我的 .gitignore 文件配置错误,它忽略了重要的 *.meta 文件。
修复 .gitignore 并再次推送使云中的项目与我的本地版本等效,问题得到解决。
从 GAC 中删除程序集(C:\WINDOWS\assembly 文件夹 - 选择您的程序集并右键单击并卸载)。因为解决方案使用 guid 保持引用,如果该 guid 在 GAC 中,它将继续使用 GAC 版本进行编译。