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

我得到一个:

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

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】:

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

【讨论】:

    【解决方案2】:

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

    不知道为什么会这样。

    【讨论】:

      【解决方案3】:

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

      跳这个帮助:)

      【讨论】:

        【解决方案4】:

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

        【讨论】:

          【解决方案5】:

          我正在开发 VS 2017 社区版,并且在使用 CefSharp nuget 包时遇到了同样的问题。

          包已成功下载和恢复,项目可以成功构建和运行 - 只有标记表明命名空间未被识别。

          我所要做的就是打开References 部分并单击黄色感叹号之一。

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

          【讨论】:

          • 我想你会发现这只有在打开“属性”面板时才有效(右键单击有问题的引用并选择“属性”。)现在谁能解释一下为什么会这样?
          【解决方案6】:

          从 VS 2019 Enterprise“降级”到 VS 2019 Professional 后开始出现此问题。 虽然错误显示在错误窗口中,但我可以毫无问题地构建项目。 尝试了该线程和其他解决方案的许多解决方案,例如均衡目标框架、删除并再次引用、删除 .suo 文件等。 对我有用的只是删除本地存储库中的项目并从远程存储库中再次克隆它。

          【讨论】:

            【解决方案7】:

            为此苦苦挣扎了一段时间,而且不是第一次。过去通常是配置不匹配,但这次不是。

            这一次原来是自动生成绑定重定向在我的应用程序中设置为true

            确实,如果我在我的库中将它设置为 true,那么我的库对于 Microsoft.Reporting 命名空间中的类型会收到此错误,如果我在我的应用程序中将其设置为 true,那么我的应用程序会收到此错误我的库中的类型错误。

            此外,对于我的库,该值似乎默认为 false,但对于我的应用程序,该值默认为 true。因此,如果我没有指定任何一个,我的库构建得很好,但我的应用程序会收到我的库的错误。因此,我必须在我的应用程序中专门将其设置为 false,否则我将收到此错误,但不说明原因。

            我还发现,如果项目未使用 sdk csproj,我将收到此消息无论设置如何。一旦我转换为 sdk csproj,设置就会有所不同。

            另外,就我而言,这一切似乎都与 Microsoft.ReportingServices.ReportViewerControl.Winforms nuget 包有关,它位于我的根库中。

            【讨论】:

              【解决方案8】:

              “使用系统;”时出现此错误将新库项目添加到我的 VS2019 解决方案后。将包 Newtonsoft.Json(currentversion) 添加到库项目解决了该问题,因为 Newtonsoft.Json 的依赖项包括库的依赖项下的 NETStandard.Library 并产生警告图标。在我安装 Newtonsoft.Json 之前,主项目有一个错误,所以我认为它也适用于库;确实如此。

              【讨论】:

                【解决方案9】:

                我在项目资源管理器中打开了项目下方的引用,将鼠标悬停在其中一个丢失的引用上,然后很快,它找到了所有内容。然后我就可以成功构建了。

                运行 Visual Studio Community 2019,版本 16.8.4

                【讨论】:

                  【解决方案10】:

                  确保您指的是为项目/文件指定的命名空间。我的问题是我从另一个项目中复制了一个文件并忘记更改命名空间。

                  【讨论】:

                    【解决方案11】:

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

                    【讨论】:

                      【解决方案12】:

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

                      【讨论】:

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