【问题标题】:Getting "type or namespace name could not be found" but everything seems ok?获取“找不到类型或名称空间名称”但一切似乎都还好?
【发布时间】:2021-07-07 07:12:25
【问题描述】:

我得到一个:

找不到类型或命名空间名称

VS2010 中的 C# WPF 应用程序出错。这部分代码编译得很好,但突然我收到了这个错误。我已经尝试删除项目参考和using 语句,关闭 VS2010 并重新启动,但我仍然遇到这个问题。

任何想法为什么会发生这种情况,我似乎在做正确的事情参考和using 声明?

我还在 VS2010 中注意到该命名空间的智能感知工作正常,所以看起来 VS2010 有项目引用并且一方面可以看到命名空间,但在编译期间看不到它?

【问题讨论】:

  • 关闭并重新启动 Visual Studio 可能会起作用。有时似乎会“卡住”
  • 指导:1) 程序集加载?,2) 程序集加载与原始程序集匹配?,3) 指向旧的或无有效引用的“使用”指令?,4) .csproj 清单包含源无效? , 5) 在整个解决方案(每个类库和项目)中查找正则表达式的搜索工具。 5)检查项目设置的网络框架版本构建选项(团队协作带来这种问题,你必须同意网络框架。双方构建版本)6)之后清理并分别构建每个,最后包括所有引用到目标项目/类库。我应该工作!
  • 检查是否引用了 dll。 Dll 位于解决方案目录的 bin 文件夹内。
  • 您是否更改了引用某些 nuget 包的项目的嵌套层次结构?试试这个解决方案 - Nuget Packages are there but missing References

标签: c# visual-studio reference namespaces directive


【解决方案1】:

首先,我将验证您的项目生成的信息没有损坏。对您的解决方案进行清理和重建。

如果这没有帮助,我在过去看到设计器问题的一件事是打开一个 Windows 窗体项目,然后再次关闭它。不过,这有点像鸡内脏,所以不要屏住呼吸。

【讨论】:

  • 我已尝试清理并重建您的解决方案,但没有运气。尝试仅删除/添加/清理/重建 WPF 应用程序项目,但仍然没有运气。 :(
  • 清理后重建修复了该问题。然而,这个问题每天都会出现。至少在我彻底解决之前我可以完成我的事情。
【解决方案2】:

您也可以尝试删除您认为遇到问题的代码,并查看它是否在不引用该代码的情况下编译。如果没有,请修复问题,直到它再次编译,然后重新处理您的怀疑问题代码。有时,当编译器不喜欢其他东西时,我会收到关于我知道是正确的类或方法的奇怪错误.一旦我修复了它真正挂断的东西,这些“幻影”错误就会消失。

【讨论】:

    【解决方案3】:

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

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

    1. 引用完整框架项目的客户端配置文件项目;或
    2. 针对新框架版本的旧框架版本

    例如,当应用程序设置为以 .Net 4 Client Profile 框架为目标,并且它引用的项目以完整的 .Net 4 框架为目标时,就会发生这种情况。

    所以为了更清楚:

    • 项目 A 以 Client Profile 框架为目标
    • 项目 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 的新项目,然后您从新项目中引用那些旧项目)

    【讨论】:

    • 非常好 - 这很有效 - 我必须升级我的 WPF 应用程序客户端才能使用完整的 .NET Framework 4。不确定这会对客户端占用空间产生什么影响?我确实尝试将我必须的库降级到 .Net 4 客户端配置文件,但是当我这样做时,它与我刚开始使用的最近的 Quartz.net 3rd 方库有类似的问题。因此,在我的库项目中使用 Quartz.net 似乎最终迫使我不得不在我的 UI WPF 应用程序中使用完整的 .Net 4 框架。
    • 谢谢 - 这刚刚有帮助。我最近将解决方案从 VS2010 移到了 VS2012,并在 VS2012 中创建了一个新的类库。突然之间我收到了这个错误,当然这是因为新的类库针对.NET 4.5,而引用它的项目针对.NET 4.0。将新库降级到目标 4.0 修复了它。
    • 如果 Visual Studio 能给你一些提示,那就太好了!
    • 虽然这个答案很好地描述了需要做什么......它没有关于如何去做的建议,这将是一个很好的补充
    • 即使是我们当中最优秀的人,有时也根本不需要做一些任务。我不确定我是如何从不需要更改框架的,虽然我现在找到了它,但我以前没有想到过。这不是答案的破坏者,只是我发现最好的答案可以作为“描述问题,陈述解决方案,展示如何解决它”的一站式服务
    【解决方案4】:

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

    【讨论】:

      【解决方案5】:

      我们有一个奇怪的案例,我刚刚在一个解决方案中解决了这个问题。主项目中的“使用”语句前面有一个隐藏/空白字符。该项目将构建良好,网站运行良好,但无法构建引用它的单元测试项目。

      【讨论】:

        【解决方案6】:

        这个对我有用。在您的班级中,定义了班级名称,例如:公共班级 ABC,删除一个字符并稍等片刻。您的错误列表将增加,因为您更改了名称。现在放回您输入的字符。这对我有用,希望它也对你有用。祝你好运!!!

        【讨论】:

          【解决方案7】:

          在我的情况下,问题是在将命名空间更改为与另一个项目中的完全相同之后(故意),程序集的名称也被 VS 更改了,所以有两个同名的程序集,一个覆盖另一个

          【讨论】:

          • 在哪里可以编辑程序集的名称以将其更改为正确的名称?
          • 在项目文件 (.csproj) 中手动或通过右键单击项目 -> 属性
          【解决方案8】:

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

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

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

          Boom Shankar。

          【讨论】:

            【解决方案9】:

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

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

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

            当我右键单击项目并仅构建它而不是整个解决方案时,我没有收到错误。

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

            为此:

            1. 我在解决方案资源管理器中右键单击我的解决方案并选择 “属性”
            2. 然后在“Common Properties”中选择“Project Dependencies”。
            3. 然后在“项目”下拉菜单中,我选择了 依赖于图书馆,并且
            4. 选中“取决于”下找到的库旁边的框

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

            【讨论】:

            • 感谢您提供查看警告的提示。我的问题是我的测试项目需要为 Bcl 安装 NuGet 包,因为我的主项目正在引用它。
            • 谢谢!这促使我找到了我遇到的问题。原来我有 两个 对依赖项项目的引用,其中一个优先的是 bin 文件夹中先前构建的 DLL。我删除了 DLL 和恶意引用并进行了重建,然后一切都正确编译了。
            【解决方案10】:

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

            【讨论】:

              【解决方案11】:

              我遇到的一个更棘手的情况是: 项目一针对安装了Microsoft.Bcl.Async 包的4.0 完整框架。 项目二以 4.0 完整框架为目标,但在引用项目一类时无法编译。

              一旦我在第二个项目上安装了 Async NuGet 包,它就可以正常编译了。

              【讨论】:

              • 啊,谢谢。我的便携式项目在 Xamarin Studio 上编译得很好,而在 Visual Studio 上它会因此而失败。我认为 XS 做了一些“魔术”,让它在缺少隐式引用时编译。
              【解决方案12】:

              我知道这是在踢死马,但我遇到了这个错误并且框架很好。我的问题基本上是说找不到接口,但它可以正常构建和访问。所以我开始思考:“为什么在其他人工作正常的情况下只有这个界面?”

              结果我实际上是使用 WCF 访问服务,端点接口使用的是实体版本 6,而其余项目使用的是版本 5。我没有使用 NuGet,而是简单地将 nuget 包复制到本地存储库以便重复使用并以不同的方式列出它们。

              例如EntityFramework6.dllEntityFramework.dll

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

              【讨论】:

                【解决方案13】:

                重新安装 nuget 包对我有用。在我将 .NET Framework 版本更改为与所有项目同步后,仍然为以前的版本安装了一些 nuget 包(尤其是 Entity Framework)。 Packages Manager Console 中的这个命令会重新安装整个解决方案的包:

                Update-Package –reinstall
                

                【讨论】:

                • 我面临的问题是我创建了一个新的解决方案,我添加了一个不同版本的 Nuget 包,而不是其他版本。然后,当我运行Update-Package -reinstall 时,我在所有解决方案中都遇到了几个错误,其中包括这个包的不同版本。我全部更新然后它终于运行了。它还修复了 package.json 文件中的引用从 45 到 452,因为我之前也更改了目标版本。
                • 为我工作,我不得不在降级时从引用中删除 Sytems.Net.Http
                • 这也是对我有用的。运行命令,然后取消执行导致的挂起更改,我的 sln 恢复正常
                • 它对我有用,它向我展示了我当前框架不支持的参考
                • 这对我有用,并且消失的错误与安装的任何 nuget 包完全无关。
                【解决方案14】:

                在我的情况下,我有一个由外部依赖项 (xsd2code) 构建的文件,并且不知何故,它的 Designer.cs 文件没有被 VS 正确处理。在 Visual Studio 中创建一个新文件并将代码粘贴到其中对我来说是诀窍。

                【讨论】:

                  【解决方案15】:

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

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

                  一旦我意识到这一点,修复就很简单了:将项目文件设置为可写,将丢失的文件读取到项目中。现在一切正常。

                  【讨论】:

                    【解决方案16】:

                    对于在尝试将网站发布到 Azure 时遇到此错误的任何人,以上看起来很有希望的解决方案都没有帮助我。我在同一条船上 - 我的解决方案本身就很好。我最终不得不

                    1. 删除我的解决方案中的所有 nuget 包。
                    2. 关闭并重新打开我的解决方案。
                    3. 重新添加所有 nuget 包。

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

                    【讨论】:

                      【解决方案17】:

                      我遇到了同样的问题。一天晚上,我的项目将在第二天早上编译错误!。

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

                      System.ComponentModel.ISupportInitialize 不知何故变成了“blahblah.System.ComponentModel.ISupportInitialize”

                      如果你和我一样,vs 这样做是一件很粗鲁的事情

                      【讨论】:

                        【解决方案18】:

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

                        然后,我右键删除它,重新正确添加dll引用,问题就解决了。

                        【讨论】:

                          【解决方案19】:

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

                          【讨论】:

                          • 在 VS 解决方案中发现任何引用问题时强烈推荐此技巧。在我添加了一个针对更高版本的 .NET 框架的新项目后,它解决了我在 VS2017 中的问题。我敢打赌有一些缓存被清除了。
                          • Same here:这是有帮助的(我也没有其他版本问题)。我收到每个打开的文件的错误消息,最多 400 多个......尽管构建/运行不是问题。另外:ReSharper 的解决方案范围分析也显示了相同的错误。
                          • 这个技巧也帮了我。甚至没有任何目标版本差异。构建是可能的,Rider 没有显示任何问题,但 VS 坚持认为所有项目引用都丢失了......
                          • 编译器根据项目构建顺序进行编译,因此如果一个项目中出现真正的错误,它可能会迷失在“找不到类型或命名空间”错误的海洋中 -因为它只是在发现错误时退出,并且不会更新引用。如果没有列出太多错误,您应该能够找到真正的错误。不幸的是,我有 100 多个,所以这个技巧真的帮助了我。我猜 intelisense 不关心构建顺序,只是单独编译项目,这就是为什么你不会收到 intelisense 错误。
                          • 以上建议在 VS2019 中帮助了我
                          【解决方案20】:

                          我遇到了类似的问题:编译器无法检测到同一项目中的文件夹,因此链接到该文件夹​​的 using 指令产生了错误。就我而言,问题源于重命名文件夹。即使我更新了该文件夹内所有类的命名空间,项目信息也无法更新。我尝试了一切:删除 .suo 文件以及 bin 和 obj 文件夹,清理解决方案,重新加载项目 - 没有任何帮助。 我通过删除文件夹和其中的类、创建一个新文件夹并在该新文件夹中创建新类来解决问题(只是在新文件夹中移动类没有帮助)。

                          PS:就我而言,我正在开发一个 Web 应用程序,但这个问题可能会出现在不同类型的项目中。

                          【讨论】:

                            【解决方案21】:

                            就我而言,我进入了解决方案属性,并确保在两个项目的配置中都选中了“构建”。我的主要项目没有检查。

                            【讨论】:

                              【解决方案22】:

                              有同样的错误,我的故事如下: 在错误合并(通过 git)之后,我的一个 .csproj 文件重复了 compile 条目,例如:

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

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

                              【讨论】:

                              • 我在 VS 2019 中遇到了类似的错误合并问题。项目编译成功,但不是解决方案。该项目实际上有一个错误(非常奇怪)。它失败是因为引用了一个先前已删除但随后从合并中重新添加的额外文件。我删除了文件,清理了 .csproj 文件,重新构建,所有的引用又开始工作了。
                              【解决方案23】:

                              我在尝试使用作为代理在本地计算机上运行的 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复制到那里。

                              【讨论】:

                                【解决方案24】:

                                它甚至发生在 Visual Studio 2017 中。

                                1. 重启 Visual Studio
                                2. 清理项目构建失败。
                                3. 重建项目。

                                【讨论】:

                                  【解决方案25】:

                                  我的情况与此处讨论的相同,但在我从参考列表中删除 System.Core 参考之前没有任何解决方案(没有它一切正常)

                                  希望它对某人有所帮助,因为这个问题非常令人沮丧

                                  【讨论】:

                                  • 这正是我的问题。我删除了 System.Core 并重新构建,错误立即自行解决。感谢一百万为我省去了很多麻烦
                                  【解决方案26】:

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

                                  这是我设法解决此问题的方法:

                                  1. 卸载引用的项目
                                  2. 在 VS 中打开 .proj 文件(我正在寻找重复文件,正如有人建议的那样)
                                  3. 再次重新加载项目(我没有更改甚至保存 proj 文件,因为我没有任何重复项)

                                  【讨论】:

                                    【解决方案27】:

                                    要解决此问题,还可以删除并重新创建相关解决方案的 *.sln.DotSettings 文件。

                                    【讨论】:

                                      【解决方案28】:

                                      在我的例子中,添加 dll 作为参考会导致 type or namespace name could not be found 错误。但是,将dll文件直接复制并粘贴到bin文件夹中即可解决该错误。

                                      不知道为什么会这样。

                                      【讨论】:

                                        【解决方案29】:

                                        我知道这个线程很旧,但无论如何我要分享,我必须安装导入程序集的所有第三方依赖项 - 因为导入的程序集没有包​​含在 Nuget 包中,因此它的依赖项丢失了。

                                        跳这个帮助:)

                                        【讨论】:

                                          【解决方案30】:

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

                                          【讨论】:

                                            猜你喜欢
                                            • 2011-03-19
                                            • 1970-01-01
                                            • 1970-01-01
                                            • 2017-07-12
                                            • 2011-05-13
                                            • 1970-01-01
                                            • 2012-06-19
                                            相关资源
                                            最近更新 更多