namespace commandTrees is not visiable

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