类型或命名空间不存在

发布于 2024-11-18 02:36:48 字数 2371 浏览 2 评论 0原文

好吧,我之前已经遇到过这个问题一百万次了,并且之前已经被回答过 100 万+1 次了。

然而,再一次。我有 3 个项目,A、B 和 C,每个项目都有一个 DLL。每个项目都是.Net 4.0(不是客户端构建,完整的4.0)。项目 C 引用 A 和 B。它们被作为项目引用,并且输出设置为本地复制。

在 C 中,我的 .cs 文件中有两个 using 语句:

using A;
using B;

当我编译时,我收到找不到 B 的抱怨。 A 很好。 B 取决于 A。

我到底该怎么办?我删除并重新添加,关闭VS2010,重新打开它,查看.csproj文件。我就是无法得到它。又是第一百万次。

请有人给我足够的理智,让我一劳永逸地了解这个来源!

是的,这可能在 StackOverflow 的某个地方得到了答案,但在我迄今为止检查过的任何最佳答案中都没有。这些术语太通用而无法使用,太多问题的答案是“呃,添加参考文献”。我已经过了那个阶段了。

这是我得到的错误。有3种,但从以往的经验来看,最后一种才是真正的。

Error   130 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' does not contain a definition for 'Database' and no extension method 'Database' accepting a first argument of type 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' could be found (are you missing a using directive or an assembly reference?) 

Error   114 'object' does not contain a definition for <blah>

Error   59  The type or namespace name '<blah>' could not be found (are you missing a using directive or an assembly reference?)    

啊哈,我查看了警告,而不仅仅是错误,这就是我所看到的:

Warning 69  The referenced project '..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj' does not exist.  AWI.WWG.EXPMRI.MriUpload.Objects

在本例中,.csproj 文件是“B”。即使我删除并重新添加项目引用,我还是得到了这个。但我感觉我离自己越来越近了!

嗯,我刚刚找到了另一个 DLL,将其命名为“D”,“A”引用了它。当我将它添加到项目中时,我开始收到抱怨:

----------------
The  Add Reference Dialog could not be shown due to the error:

The specified path, file name, or both are too long.  The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
----------------

这可能是相关的,还是只是另一个干扰?


好吧,我发现了这个问题,虽然我不明白。

当我通过 IDE 添加引用时,它会将其添加到“C”的 csproj 文件中:

<ProjectReference Include="..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj">

这不会编译,它警告找不到引用的项目,然后会发生所有这些错误。但后来我将 ProjectReference 更改为以下内容:

<ProjectReference Include="C:\...\Partners.Connectors.Base.2010.csproj">

...并且它工作得很好。请注意,这些路径的长度都不接近 256 个字符。完全合格的只有 135 个字符。但也许 IDE 正在对路径进行一些愚蠢的修饰。

Ok, I have had this one a million times before and it's been answered 1 million +1 times before.

And yet, once again. I have 3 projects, A, B, and C, each a DLL. Each project is .Net 4.0 (not the client build, full 4.0). Project C references A and B. They are referenced as projects, and the output is set to copy locally.

In C, I have two using statements in my .cs file:

using A;
using B;

When I compile, I get the complaint that is cannot find B. A is fine. B depends on A.

What the heck should I do? I've removed and re-added, closed VS2010, re-opened it, looked at the .csproj file. And I just cannot get it. Again, for the millionth time.

Someone please slap enough sense into me that I learn the source of this once and for all!

And yes, this is probably answered somewhere in StackOverflow, but not in any of the top answers I've checked so far. The terms are just too generic to be of use, too many questions where the answer is "duh, add a reference". I'm past that point.

Here are the errors I get. There are 3 kinds, but from past experience, the last one is the true one.

Error   130 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' does not contain a definition for 'Database' and no extension method 'Database' accepting a first argument of type 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' could be found (are you missing a using directive or an assembly reference?) 

Error   114 'object' does not contain a definition for <blah>

Error   59  The type or namespace name '<blah>' could not be found (are you missing a using directive or an assembly reference?)    

Aha I looked at the warnings, not just the errors, and here is what I see:

Warning 69  The referenced project '..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj' does not exist.  AWI.WWG.EXPMRI.MriUpload.Objects

That .csproj file is the "B" in this case. Even though I remove and re-add the project reference I get this. But it feels like I'm getting closer!

Hmm, I just found another DLL, call it "D", which "A" references. When I add it to the project, I start to get the complaint:

----------------
The  Add Reference Dialog could not be shown due to the error:

The specified path, file name, or both are too long.  The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
----------------

Could this be related, or just another distraction?


Ok, I found the issue, though I do not understand it.

When I add the reference through the IDE, it adds this to the csproj file of "C":

<ProjectReference Include="..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj">

This does not compile, it WARNS that it cannot find the referenced project, then all those ERRORs happen. But then I change the ProjectReference to the following:

<ProjectReference Include="C:\...\Partners.Connectors.Base.2010.csproj">

... and it works just fine. Note that neither of those paths are anything close to 256 characters. The fully qualified one is only 135 characters. But perhaps the IDE is doing some silly decoration of the path.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(12

維他命╮ 2024-11-25 02:36:48

该解决方案与 Windows 中的文件路径限制有关,它们是 IDE 将相对路径转换为完整路径的方式,如 此博客

直接的解决方案是手动编辑 csproj 文件以使用绝对路径。在重新添加引用之前,绝对路径将一直有效。有一天我可能会缩短我的文件夹,但目前这不是首要任务。

如果您怀疑存在此问题,请查看编译器发出的警告消息。我经常自己关闭这些功能,只查看错误。但有关“引用的项目不存在”的警告是为我解决此问题的线索。

如果其他链接消失,这里是 MS 文章的链接。
http://support.microsoft.com/kb/2516078

值得注意的是,同样的错误表现为各种问题,例如客户端框架定位问题,并在引用加载失败时记录为警告。据推测,引用错误只是一个警告,因为如果实际上不需要引用,那也没关系。

The solution has to do with the file path limits in Windows, and they way the IDE translates relative paths into full ones, as explained in this blog.

The immediate solution is to edit the csproj file manually to use the absolute path. Until the reference is re-added, the absolute path will be valid. One day I may shorten my folders, but it's not top priority at the moment.

If you suspect you have this issue, look at the Warning messages from the compiler. I often have these turned off myself, only looking at errors. But the warning about "the referenced project does not exist" was the clue that solved this for me.

In case the other link disappears, here is the link to the MS article.
http://support.microsoft.com/kb/2516078

It is worth noting that this same error manifests for a variety of issues such as client-framework-targeting issues, and is logged as a warning when a reference fails to load. Presumably the reference error is only a warning because if the reference is not actually needed it doesn't matter.

伊面 2024-11-25 02:36:48

我会确保您的项目已包含对程序集的引用。

在此处输入图像描述

我会检查构建顺序是否与您的依赖项相匹配

在此处输入图像描述

最后,如果一切设置正确,您应该看到以下构建顺序:

这不是您的问题,但为了完整起见,我应该补充一点要检查的另一件事(如果您的项目面向 .NET Framework 3.5 或更高版本)是两个项目的目标框架是否匹配。如果您要链接完整版本框架中针对客户端配置文件的内容,您还会收到“未找到”错误:

“在此输入图像描述”

I would make sure that your project has included the references to the assemblies.

enter image description here

I would check that the build order matches your dependencies

enter image description here

Finally, if everything is setup properly, you should see the following Build Order:

enter image description here

Doesn't look like this is your problem, but for completeness, I should add that another thing to check (if your project targets the .NET Framework 3.5 or above) is that the Target Framework for both projects match. If you are linking something that targets the Client Profile from a full version of the Framework, you will also get a 'not found' error:

enter image description here

小忆控 2024-11-25 02:36:48

转到警告部分并解决所有警告,然后您就完成了...

警告部分将告诉您所引用的项目需要哪些内部 dll 依赖项。

Go to warning section and resolve all warning and you are done...

The warning section will tell you what all internal dlls dependencies are needed for the project you are referencing to.

缱倦旧时光 2024-11-25 02:36:48

我知道这不是您问题的答案,但是当您尝试引用 .net 版本高于您正在使用的项目时,错误非常相似。 IE:您无法从 .net 3.5 引用 .net 4.5 的内容

I know this isn't the answer to your issue, but the error is quite similar when you are trying to reference a project with a higher .net version than the one you're using. IE: you can't reference something with .net 4.5 from .net 3.5

贱贱哒 2024-11-25 02:36:48

基本上,这听起来像是缺少参考。

我能想到的一些健全性检查是:

  1. 您确定生成错误的项目是 C 吗?
  2. 您确定您在使用时没有在名称空间 B 中犯拼写错误吗?
  3. 难道在编译C之前B中已经出现了编译错误吗? (这可能会导致编译器无法在 B 中找到命名空间)。
  4. 您还有其他编译错误或警告吗?

编辑

另一个建议:B程序集中的类是否定义为public

Basically, this sounds like a missing reference.

Some sanity checks I can think of are:

  1. Are you sure that the project that generates the error is C?
  2. Are you sure you are did not make a spelling mistake in the namespace B in your using?
  3. Can there have been some compilation error in B before compiling C? (That may cause the compiler to fail finding the namespace in B).
  4. Do you have any other compilation error or warning?

Edit

Another suggestion: is the class in the B assembly defined as public?

万人眼中万个我 2024-11-25 02:36:48

我在更新我们通常通过 NuGet 使用的项目时得到了这个。我想,如果我只是将更新后的构建 dll 复制到软件包文件夹中,我就可以测试它,而无需在我的计算机上设置 NuGet,但事情并没有那么简单,因为我的应用程序仍在寻找旧版本号。希望能帮助那里的人。

I got this when updating a project that we normally use via NuGet. I thought if I simply copied the updated built dll over to the packages folder I could test it without having to setup NuGet on my machine, but it wasn't that simple because my app was still looking for the old version number. Hope that helps someone out there.

赠佳期 2024-11-25 02:36:48

我在 C# 6.0 中使用 global::[namespace][type I Want to use] 解决了这个问题

I solved this using global::[namespace][type I want to use] in C# 6.0

浅暮の光 2024-11-25 02:36:48

经过几个小时的挫折后,我发现了使用 VS2017 解决方案解决此问题的以下过程:

Insure that all reference assemblies have been recognized and have current properties.

If assemblies do not show proper reference, right click the entry
and view properties.  This action often resets the reference. This
action must be completed for each project in the solution.

After resolving all references, if the error continues, delete the
following:

        -The Obj folder

        -The Bin folder

        -Reference to the offending assembly

        -Clean and Rebuild the solution.  Errors should occur.

        -Re-reference the needed assembly.

The editor should no longer show the namespace error and build should succeed.

After many hours of frustration, I discovered the following process to resolve this issue with a VS2017 solution:

Insure that all reference assemblies have been recognized and have current properties.

If assemblies do not show proper reference, right click the entry
and view properties.  This action often resets the reference. This
action must be completed for each project in the solution.

After resolving all references, if the error continues, delete the
following:

        -The Obj folder

        -The Bin folder

        -Reference to the offending assembly

        -Clean and Rebuild the solution.  Errors should occur.

        -Re-reference the needed assembly.

The editor should no longer show the namespace error and build should succeed.
臻嫒无言 2024-11-25 02:36:48

创建干净的项目并测试您在项目中使用的最小程序集集。这样您就可以确定您的解决方案中是否有问题或者新创建的项目是否有相同的症状。如果是这样,那么可能 VS、.net 等已损坏或发生其他情况。

Create clean project and test minimal sets of assemblies you use in your project. This way you will be sure if there is something bad in your solution or if newly created project has same symptoms. If so, then maybe VS, .net etc is corrupted or something.

听风念你 2024-11-25 02:36:48

在尝试解决另一个问题时,我突然开始遇到此错误,

我通过转到 Solution=>properties=>project dependency 解决了这个问题,并且我收到命名空间错误的两个项目的所有依赖项都已关闭。我选中了复选框并重新构建了解决方案,没有出现任何错误。

I started getting this error suddenly while trying to solve another problem

I solved this by going to Solution=>properties=>project dependencies and all the dependencies were off for the two projects I was getting a namespace error for. I checked the check boxes and rebuilt the solution with no errors.

咽泪装欢 2024-11-25 02:36:48

在 VS2017 中,当我的解决方案中的项目被卸载时,这个问题就出现了。

With VS2017, this issue came up for me when the project in my solution was unloaded.

兮颜 2024-11-25 02:36:48

就我而言,我必须检查“WorkFlow”1 的实现位置。
因此,我比较了使用此“工作流程”的项目/类库的框架版本。
检查所有项目/类库使用相同的框架后,我必须在导致构建错误的项目/类库中搜索“.WorkFlow”。

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Workflow.Targets(121,5):
错误:类型或命名空间名称“WorkFlow”不存在于
命名空间 'Proyect_to_build' (您是否缺少 using 指令或
装配参考?)

事实证明,“Reference”文件夹中缺少包含“WorkFlow”的 .dll。添加.dll后,项目/类库编译成功。

同样,就我而言,我没有使用这个 .dll,我只需要编译项目/类库即可在程序的某个部分启用断点(其中根本不涉及“WorkFlow”),但是添加它之后(带有“WorkFlow”源代码的 .dll),它就编译了。


1 “工作流程”来自使用工作流程自定义代码的遗留代码。

In my case, I have to check where the "WorkFlow"1 was implemented.
Hence, I compare the framework version of the projects/class libraries that uses this "WorkFlow".
After check that all projects/class libraries uses the same framework, I have to search ".WorkFlow" in the project/class library that was causing the builing error.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Workflow.Targets(121,5):
error : The type or namespace name 'WorkFlow' no exists in the
namespace 'Proyect_to_build' (are you missing a using directive or an
assembly reference?)

It turns out that the .dll that contains "WorkFlow" was missing in the "Reference" folder. Once added the .dll, the project/class library compiled successfully.

Again, in my case, I wasn't using this .dll and I only need compile the project/class library for enable breakpoints in a certain part of the program (where "WorkFlow" is not involved at all), but well, after add it (the .dll with the "WorkFlow" source code), it compiled.


1 "WorkFlow" comes from a legacy code using custom code for WorkFlows.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文