命名空间命令树不可见 [英] namespace commandTrees is not visiable

问题描述

向下投票
最喜欢
 使用 System.Data.Common.CommandTrees; 
  显示错误如下：
 
  错误3名称空间'System.Data.Common'中不存在类型或命名空间名称'CommandTrees'（你是否遗漏了）汇编参考？） 
   visual studio  2013 。

解决方案

在框架参考中添加对System.Data.Entity.dll的引用

除了解决方案1：



但这里有一个微妙的观点，同时也是微不足道的。这些问题和答案并不能解决所有情况下的参考问题。这是因为报告的编译错误基于 使用指令（不要与 使用声明），更重要的是，不是该指令的别名形式。在生成此错误的那一刻，编译器还没有知道什么类型的命名空间导致问题。



首先，让我解释一下为什么回答这个问题不需要任何试验。在这个特例的例子中，我们在Google上搜索名称空间System.Data.Common.CommandTrees。它没有给我们任何程序集名称或主模块名称： https://msdn.microsoft.com/en-us/library/system.data.common.commandtrees%28v=vs.110%29.aspx [ ^ ]。



为什么不呢？因为两个或更多不同的程序集可以在同一名称空间中声明不同的类型。要回答这个问题，只需指出一个程序集就足够了，然后引用这个程序集就可以编译这个问题。因此，只需单击命名空间中的任何程序集级别类型即可;它将给出程序集，在本例中为System.Data.Entity.dll：

https://msdn.microsoft.com/en-us/library/system.data.common.commandtrees.dbaggregate（v = vs.110 ）.aspx [ ^ ]。



在大多数情况下，汇编中声明的所有类型都将通过仅添加一个来引用装配到参考。但它无法保证。无论如何，问题得到解答，使用行被编译。但是进一步的代码很多都没有编译，因为它可能需要一些其他程序集引用，尽管名称空间相同。任何人都可以定义不同的相同名称空间;我甚至不称它为不合理。这是BCL中最简单的例子：



假设我们只引用 System 程序集，并写

 使用系统;  //  将编译 
 
  //   ...  
 
行动myMethod = 新行动（（）= >  {Console.WriteLine（ 做一些）;}）; 





尽管控制台只是 System.Console 和操作是系统.Action 。为什么？这是因为 System.Action 在System.Core中定义，也需要引用。



顺便说一下，我在上一篇文章 Action ，特别是通用 Action 类型的原理。 href =http://www.codeproject.com/Tips/137796/Hide-Ad-hoc-Methods-Inside-the-Calling-Method-s-Bo>隐藏调用方法正文中的特殊方法 [ ^ ]。



对于某种结论，我想强调别名表单的健壮性 使用指令： https://msdn.microsoft.com/en-us/library/sf0df423.aspx [ ^ ]。



不仅了解th问题可以帮助提出更正确的论坛问题，但它可以作为回答所有这类问题的完整说明。

- SA

down vote
favorite
using System.Data.Common.CommandTrees; 
It is showing an error as below :

"Error 3 The type or namespace name 'CommandTrees' does not exist in the namespace 'System.Data.Common' (are you missing an assembly reference?) "
in visual studio 2013.

解决方案

Add a reference to System.Data.Entity.dll in the Framework references

In addition to Solution 1:

But here is a subtle point here, totally trivial at the same time. Such questions and answers don't resolve the reference problem in all cases. This is because reported compilation error is based on using directive (not to be confused with using statement), and, importantly, not the alias form of this directive. At the moment of generation of this error, the compiler does not yet "know" what type of the namespace causes the issue.

First of all, let me explain why answering of this question does not need any trial. On the example of this particular case, we search Google for the namespace "System.Data.Common.CommandTrees". It gives us no assembly name or main module name: https://msdn.microsoft.com/en-us/library/system.data.common.commandtrees%28v=vs.110%29.aspx[^].

Why not? Because two or more different assembly can declare different types in the same namespace. To answer the question, it's enough to point out just one assembly, then referencing this assembly will make the line in question compile. So, it's enough to click on any assembly-level type in the namespace, any at all; it will give the assembly, in this case, "System.Data.Entity.dll":
https://msdn.microsoft.com/en-us/library/system.data.common.commandtrees.dbaggregate(v=vs.110).aspx[^].

In most cases, all the types declared in assembly will be referenced by adding just one assembly to references. But it cannot be guaranteed. No matter, the question is answered, the "using" line is compiled. But further code many not compile, because it may need some other assembly reference, despite the same namespace. Anyone can define identical namespaces in different; and I cannot even call it unreasonable. Here is the simplest example from BCL:

Let's say, we reference only System assembly, and write

using System; // will compile

// ...

Action myMethod = new Action(() => { Console.WriteLine("do something"); });

The code won't compile despite the fact that Console is just System.Console and Action is System.Action. Why? This is because System.Action is defined in "System.Core" which needs to be referenced, too.

By the way, I explained the rationale behind using Action, especially generic Action types, in my past article Hide Ad-hoc Methods Inside the Calling Method’s Body[^].

For a kind of conclusion, I want to emphasize the robustness of the alias form of using directive: https://msdn.microsoft.com/en-us/library/sf0df423.aspx[^].

Not only understanding of this matter can help asking more correct question of this forum, but it can be used as a complete instruction for answering all the questions of this kind.

—SA

这篇关于命名空间命令树不可见的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！