无法识别命名空间(即使它存在)

我得到了这个错误:

找不到类型或命名空间名称“ AutoMapper”(是否缺少 using 指令或程序集引用?)

有趣的是,我已经在我的项目中提到了这一点:

ProjectThatFails

这是我的暗号:

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 文件。它们都很好用。

下面是其中一个的截图:

ProjectThatWorks

下面是代码(编译得很好) :

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>();
}

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

我错过了什么?

我试过:

  1. 重新启动 VisualStudio
  2. 没有使用语句的引用(即 AutoMapper.Mapper.CreateMap)
  3. 清洁及重建

还有别的办法吗?

235147 次浏览

检查以确保项目没有设置为使用.NETFramework4客户端配置文件。

您可以通过右键单击您的项目(而不是解决方案)来检查/修改它,选择 < em > 物业 -> 申请书-> 目标框架。目标框架是该页面上的一个下拉列表。

这是 VisualStudio 中的一个问题(我甚至称之为 bug)。属性中排除的程序集。NETFramework4客户端配置文件。由于您的项目使用的是该版本的框架,因此它会中断。

时,类似的错误将传播到生成过程。正在引用的项目的 NETFramework 版本高于正在引用的项目。也就是说。以4.5为目标的项目如果引用以4.5.1为目标的项目,也会出现同样的错误。

发生这种情况时,需要有一个更好的错误消息,因为没有合理的解释说明为什么它不会像错误消息告诉您引用已清楚引用的程序集那样构建。

让我问一个愚蠢的问题: 会不会有两个 Autapper.dll文件?一个带有 AutoMapper名称空间,一个没有?确认两个项目中的路径。

我还注意到 using命令的顺序不同。这不重要,但你试过洗牌吗?

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

我在使用 VS2005时遇到了这个问题,虽然现在 期待MS 已经解决了这个问题。.

我有一个类似的问题与参考不被认可在 VS2010和答案在这里无法纠正它。

我的解决方案中的问题与所引用的项目所在路径的扩展有关。在使用 SVN 时,我制作了一个存储库分支来进行一些测试,该分支在路径结构中增加了两个级别,因此路径变得太长,无法在 Windows 中使用。这不会抛出任何错误,但不能识别项目引用的名称空间。当我更正项目的位置,使其有一个更小的路径时,一切都进行得很顺利。

如果您的类未编译,即使它在项目中,也请检查以下内容:

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

在我的例子中,引用的 dll 是用。网络架构。在我添加了引用之后,我就可以使用它了。但是,一旦我做了一个构建,“缺少引用”错误将弹出。我刷新的 dll 错误将去,但它永远不会构建。这篇文章让我检查了框架版本,因此我可以通过构建相同版本的引用项目来解决这个问题。

这个问题已经被批准了,但是还有更多的细节没有被描述,需要被检查。

我也有这种行为,项目 B 在项目 A 中被引用,但项目 B 的名称空间在项目 A 中不被识别。经过一番挖掘,我发现我的路太长了。通过减少项目(A 和 B)的路径,引用变得可见和可用。

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

我遇到过类似的问题,名称空间/方法在执行过程中找不到,尽管在编译过程中没有问题,原因似乎是我引用的程序集被部署到了 GAC,并且从那时起就被更改了,所以当我在 Visual Studio 中引用程序集时,它使用的是最新的一个,但是在运行过程中使用了 GAC 的版本。

在我的例子中,我复制了一个类库,但没有更改项目属性中的“程序集名称”,所以一个 DLL 正在覆盖另一个..。

我通过右键单击包含文件的文件夹并选择 从项目中排除,然后再次右键单击并选择 包括在项目中(您必须首先启用 显示所有文件以使被排除的文件夹可见)来解决这个问题

在我的例子中,我只是在 VS 2015中得到了错误。在 VS 2017中打开项目时,错误消失了。

如果所有其他的答案都不能帮助你,那么这就是最简单的解决方案

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

重新启动 VisualStudio 成功了

很疯狂,我知道。

我什么都试过了。重新启动、清理、手动检入生成的 DLL (如果真的是你自己搞砸了,这对于理解是无价的)。

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

这个问题已经在原来的海报上得到了回答,但是如果有人在 MS-Test 项目中遇到这个问题:

在 Visual Studio 中,单击 Test 菜单-> Test Settings-> Default Processor Architecture,并确保该架构与正在引用的其他程序集匹配。如果另一个程序集是 x64,而您的测试设置是 x86,您可能会体验到原始海报的症状。

我在 Xamarin 项目工作,一如既往,删除 obj 文件夹和重建解决了我的问题,我的 VS 没有识别的名称空间是在我自己的项目 BTW 的代码

在我的例子中,删除/添加该程序集是有效的。

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

  1. 确保我要参考的项目列在参考文献下面
  2. 确保两个项目都使用正确的.NETFramework 版本
  3. 构建项目(单击绿色的“开始”箭头)

我感到困惑,因为在步骤1和步骤2之后我仍然得到了错误,但是构建项目似乎解决了这个问题。

我也遇到过类似的问题,需要一些时间来解决,所以我想和大家分享一下:

在我的示例中无法解析的命名空间是 公司,项目,通用,型号 EF。我在新的 公司。项目。业务逻辑。通用名称空间中添加了一个文件。

大多数文件都有一个

using Company.Project;

然后将模型引用为 普通型号 EF

using Company.Project.BusinessLogic;

因为 VS 无法确定使用哪个命名空间。

解决方案是将第二个名称空间更改为 公司。项目。业务逻辑。公共服务

重新启动 VisualStudio2019-成功了。

虽然承认这是一篇较早的文章,但我还是觉得应该把这个建议添加到回复列表中,因为我没有看到它被提及。

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

右键单击出现问题的项目,选择 Build Dependences —— > Project Dependences,并确保选择所需的 Project 作为参考。

我也有同样的问题,但是没有一个建议的解决方法是有效的。我以前从未在 VS 中看到过这样的怪异(目前正在运行 VS 2019)

我检查了潜在的名称空间问题和大量更明显的原因,没有一个是有意义的。Intellisense 甚至承认其他项目的存在,并建议使用声明,但即使在添加了使用参考; VS 2019仍然不承认其他项目。

按照描述的方式强制依赖关系解决了这个问题。

我的解决方案是删除。从我的解决方案文件夹的文件夹。这将重置解决问题的智能感知。你需要打开“隐藏的项目”(如果运行窗口) ,因为它是一个隐藏的文件夹。

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