名称空间无法识别（即使它存在）[重复]

Posted 2023-02-23

【中文标题】名称空间无法识别（即使它存在）[重复]

【英文标题】：Namespace not recognized (even though it is there) [duplicate]

【发布时间】：2011-05-12 20:31:07

【问题描述】：

我收到此错误：

找不到类型或命名空间名称“AutoMapper”（您是否缺少 using 指令或程序集引用？）

有趣的是，我的项目中已经有了这个参考：

这是我的代码：

using System.Collections.Generic;
using DataContract;
using SelectorDAL;
using AutoMapper;

namespace SpecimenSelect

    public class SpecimenSelect : ISpecimenSelect
    
        public SpecimenSelect()
        
            SetupMaps();
        

        private static void SetupMaps()
        
            Mapper.CreateMap<SpecimenDetail, SpecimenDetailContract>();
        

另一个奇怪的事情是我的解决方案中有两个其他项目都使用 AutoMapper 并且引用完全相同的 AutoMapper.dll 文件。它们都工作得很好。

这是一个截图：

这是代码（编译良好）：

using System.Collections.Generic;
using AutoMapper;
using DataContract;
using SelectorDAL;

namespace PatientSelect


    public class PatientSelect : IPatientSelect
    
        public PatientSelect()
        
            SetupMaps();
        

        private void SetupMaps()
        
            Mapper.CreateMap<Patient, PatientContract>();
            Mapper.CreateMap<OrderedTest, OrderedTestsContract>();
            Mapper.CreateMap<Gender, GenderContract>();
        

两个引用似乎在属性页上具有相同的数据。

我错过了什么？

我试过了：

重新启动 Visual Studio 不使用 using 语句的引用（即AutoMapper.Mapper.CreateMap） 清理并重建

还有其他想法吗？

【问题讨论】：

引用路径不正确？也许它添加了一个绝对路径，但 DLL 已经被移动了？

【参考方案1】：

检查以确保您的项目未设置为使用 .NET Framework 4 客户端配置文件。

您可以通过右键单击您的项目（不是解决方案）来检查/更改此设置，选择 Properties -> Application -> 目标框架。目标框架是该页面上的下拉菜单。

这是 Visual Studio 中的一个问题（我什至可以称之为错误）。 AutoMapper 需要从 .NET Framework 4 客户端配置文件中排除的程序集。由于您的项目正在使用该版本的框架，因此它会中断。

当您引用的项目的 .NET Framework 版本高于进行引用的项目时，类似的错误将传播到构建过程。即，一个以 4.5 为目标的项目引用了一个以 4.5.1 为目标的项目，也会给您同样的错误。

发生这种情况时需要有更好的错误消息，因为没有合理的解释说明为什么它不会生成，因为错误消息告诉您引用已明确引用的程序集。

【讨论】：

这正是问题所在！谢谢！我同意这个错误非常具有误导性。我也不明白为什么客户端配置文件是新项目的默认设置。大多数计算机都将拥有完整的 .net 框架，对吗？ （或者 MS 只是将客户端框架放在 Windows 更新上？）无论如何，我开发的所有计算机都将具有完整的框架。我希望有一种方法可以更改新项目的默认设置，这样它确实会像这样咬我。反正。再次感谢！我被卡住了，我没想到那里看。

我遇到了完全相同的问题！即使我正确添加了引用，我的 Windows 服务项目中也无法识别这些类型。我将目标框架从 .NET Framework 4 Client Profile 更改为 .NET Framework 4。请注意，我还必须重新添加引用才能使其编译。似乎是 Visual Studio 2010 中的一个问题。来自布达佩斯的感谢和问候。

很好，这也发生在我身上。我的测试项目无法识别引用的命名空间，即使它们在那里。这是因为我将库更改为 .NET 4.5 平台，但测试项目仍为 4.0。无论如何，您的回答使我走上了正确的道路。谢谢你解决这个问题。

当我尝试在 .Net 3.5 客户端配置文件项目中使用 .Net 2.0 程序集时遇到了同样的问题。并切换到 3.5 完整配置文件解决了这个问题。

我的问题类似。这些项目使用不同的框架版本。主项目使用 4.5，新创建的项目使用 4.5.1。如果错误信息更好，那就太好了。

【参考方案2】：

让我问一个愚蠢的问题：可能有两个 automapper.dll 文件吗？一个有AutoMapper 命名空间，一个没有？确认两个项目中的路径。

我还注意到using 命令的顺序不同。没关系，但你有没有尝试过洗牌？

【参考方案3】：

可能项目的类型表处于不正确的状态。我会尝试删除/添加引用，如果这不起作用，创建另一个项目，导入我的代码，看看是否有效。

我在使用 VS 2005 时遇到了这个问题，但是 预计 MS 现在已经解决了这个特定问题..

【讨论】：

你能解决这个问题吗？

【参考方案4】：

我有一个类似的问题，在 VS2010 中无法识别引用，并且这里的答案无法纠正它。

我的解决方案中的问题与引用的项目所在路径的扩展有关。当我使用 SVN 时，我创建了一个存储库的分支来进行一些测试，并且该分支在路径结构中增加了两个级别，因此路径变得太长而无法在 Windows 中使用。这没有引发任何错误，但没有识别项目引用的命名空间。当我更正项目的位置以拥有更小的路径时，一切都很好。

【讨论】：

这对我们来说也是一个问题，它是导致问题的路径长度。在这种情况下，VS 需要更好地提供更好的错误，因为我们得到的错误非常具有误导性。

感谢您的回答，我想到了一个想法。我查看了项目的路径，发现根文件夹（由源代码树创建的文件夹）的名称中包含“%20”而不是 _。我将其更改为 _，现在一切正常。

【参考方案5】：

如果你的类没有编译，即使它在项目中，检查这些：

类名是否完全相同 名称空间是否完全相同 类属性是否显示构建操作 = 编译

【讨论】：

我用 Explorer 复制了一个 .cs 文件，然后将其包含在项目中。 VS.Net 将构建操作设置为“内容”而不是“编译”，因此无法识别命名空间。好收获！

我通过 Add -> Class 功能添加了类，并将构建操作设置为内容。只是好奇为什么？无论如何，这对我有帮助，事情如此简单，但从未遇到过。这就是为什么我什至懒得去那里看，而是用谷歌搜索。

【参考方案6】：

在我的例子中，引用的 dll 是在更高版本的 .Net Framework 中构建的。添加参考后，我可以使用它。但是，一旦我进行了构建，就会弹出“缺少参考”错误。我刷新 dll 错误会消失，但它永远不会构建。这篇文章让我检查了框架版本，因此我可以通过在相同版本中构建引用的项目来解决它。

【参考方案7】：

该问题已被授予，但还有其他尚未描述的详细信息需要检查。

我也有这种行为，项目A中引用了项目B，但是项目A中无法识别项目B的命名空间。经过一番挖掘，我发现我的路径太长了。通过减少项目（A 和 B）的路径，引用变得可见和可用。

我通过在更小的路径深度创建项目 C 来测试这个理论。我在项目 A 中引用了项目 C。这些引用按预期正常工作。然后我从解决方案中删除了项目 C，只是将项目 C 移动到与项目 B 相同的深层路径，并将项目 C 添加回解决方案，并尝试编译。然后我再也看不到项目 C 对象了。

【参考方案8】：

我在执行期间遇到了类似的命名空间/方法未找到的问题，尽管在编译期间它很好，这似乎是我引用的程序集被部署到 GAC 并且从那时起被更改了，所以当我引用了 Visual Studion 中的程序集，它使用的是最新的程序集，但在运行时使用了 GAC 的版本。

【参考方案9】：

在我的情况下，我复制了一个类库，并没有更改项目属性中的“程序集名称”，因此一个 DLL 覆盖了另一个...

【参考方案10】：

我通过右键单击包含文件的文件夹并选择 Exclude From Project 然后再次右键单击并选择 Include In Project 解决了这个问题（您首先必须启用显示所有文件以使排除的文件夹可见）

【讨论】：

我在大量文件中遇到此错误，只需删除一个并重新包含它即可解决整个解决方案的问题。

右键点击什么？ “从项目中排除”从解决方案资源管理器中删除该文件夹。没有“包含在项目中”

@FlorianWinter 要右键单击排除的文件夹，您需要启用 显示所有文件。这可以通过解决方案资源管理器进行切换，它位于 全部折叠 按钮旁边。

不知道为什么，但这在 VS2019 中有效，当时我向项目添加了一个包含新类的新文件，但无法在另一个已经有引用新类的包含项目...¯\_(ツ)_/¯

这为我解决了。这是 Visual Studio 上一个非常烦人的错误，并且经常发生。

【参考方案11】：

在我的情况下，我只在 VS 2015 中遇到了错误。在 VS 2017 中打开项目时，错误消失了。

【参考方案12】：

如果所有其他答案都没有帮助你，这必须是最简单的解决方案

我在答案中寻找我的设置有什么问题，尝试了所有这些 - 没有一个有效，然后我意识到 Visual Studio 2018 是由 Microsoft 开发的。所以我做了大多数人都会做的事情，

重新启动 Visual Studio 它奏效了

【讨论】：

为我工作，但在重新启动之前删除了 bin 和 obj 文件夹。

在我使用 *** 的所有岁月中，这是对错误（实际上提供了解决方案）的最佳咸味响应，并且它在第一次重新启动时起作用。失眠ftw！

【参考方案13】：

疯了。我知道。

在这里尝试了所有选项。重新启动、清理、手动签入生成的 DLL（这对于了解是否真的是你自己搞砸了）。

我通过在选项中将 MSBuild 的详细程度设置为“详细”来使其工作。

【讨论】：

对我来说，当配置名称为 x86 时，它是在 PlatformTarget 上设置为 AnyCpu 的构建配置。这个设置帮我找到了。

【参考方案14】：

这个问题已经为原始海报回答了，但如果有人在 MS-Test 项目中遇到这个问题：

在 Visual Studio 中，单击测试菜单 -> 测试设置 -> 默认处理器体系结构，并确保体系结构与您引用的其他程序集的体系结构相匹配。如果另一个程序集是 x64 并且您的测试设置是 x86，您可能会遇到原始发布者的症状。

【参考方案15】：

我正在处理 Xamarin 项目，并且一如既往，删除 obj 文件夹并重建解决了我的问题，我的 VS 无法识别的命名空间是我自己项目中的代码顺便说一句

【参考方案16】：

在我的情况下，删除/添加该程序集有效。

【参考方案17】：

这在 Visual Studio 2019 中发生在我身上。对我来说，我试图在我的解决方案中引用另一个项目。以下是我采取的步骤，以防它对其他人有所帮助：

确保我想参考的项目列在参考文献中 确保两个项目都使用正确版本的 .NET Framework 构建项目（单击绿色“开始”箭头）

我很困惑，因为在第 1 步和第 2 步之后我仍然收到错误，但构建项目似乎可以解决它。

【参考方案18】：

我也遇到过类似的问题，需要一段时间才能解决，所以我想分享一下：

在我的例子中无法解析的命名空间是 Company.Project.Common.Models.EF。我在新的 Company.Project.BusinessLogic.Common 命名空间中添加了一个文件。

大多数文件都有一个

using Company.Project;

然后将模型引用为 Common.Models.EF。所有的文件也有一个

using Company.Project.BusinessLogic;

由于 VS 无法确定要使用的命名空间而失败。

解决方案是将第二个命名空间更改为 Company.Project.BusinessLogic.CommonServices

【参考方案19】：

重新启动 Visual Studio 2019 - 成功了。

【讨论】：

Vaccano 写道：我试过：重新启动 Visual Studio

做到了。谢谢！

【参考方案20】：

承认这是一篇较早的帖子，但我仍然认为我会将这个建议添加到回复列表中，因为我没有看到它被提及。

如果未解析的引用存在于解决方案中另一个项目的上下文中：

右键单击有问题的项目，选择构建依赖项 --> 项目依赖项并确保选择所需的项目以供参考。

我遇到了与帖子中描述的相同的问题，但是建议的解决方法都没有奏效。我以前从未在 VS 中看到过这样的怪癖（目前正在运行 VS 2019）

我检查了潜在的命名空间问题和大量更明显的原因，但没有任何意义。 Intellisense 甚至承认了另一个项目的存在并建议了 using 语句，但即使在添加了 using 引用之后也是如此； VS 2019 仍然不会承认其他项目。

以所述方式强制依赖解决了问题。

【参考方案21】：

我的解决方案是从我的解决方案文件夹中删除 .vs 文件夹。这将重置修复问题的智能感知。您需要打开“隐藏项目”（如果正在运行 Windows），因为它是一个隐藏文件夹。

在这里找到解决方案 - https://weblog.west-wind.com/posts/2018/Aug/07/Fixing-Visual-Studio-Intellisense-Errors