We Keep Coding

Is it OK to have a namespace name which exists at two points in the tree?

Is this OK:
namespace Simple.OData
{
// Common OData functionality
}
namespace Simple.Data.OData
{
// The Simple.Data adapter for OData
}
It feels like it might be wrong, but I'm not sure.

It's certainly valid - consider System.Xml.Linq and System.Linq. I can't immediately foresee any problems... but that's not to say it's necessarily a good idea.
Personally I prefer Simple.Data.OData over Simple.OData.Data, as I suspect this is primarily aimed at people who are using Simple.Data, but happen to be using OData - not people who are focused on OData. Again, this is like LINQ: System.Xml.Linq is an XML API which plays will with LINQ; it's not a LINQ "provider" as such.
Basically it's the same sort of problem as "I have a converter to convert from type A to type B; do I put it near type A or type B?" - but with namespaces. My experience is that usually more head-scratching goes into thinking of the best thing to do than the problems that would be caused by taking either approach...

More correct would be, namespace Simple.OData.Data.
This is because the Data namespace should be grouped with the other classes relating to OData.
If you're thinking along with lines of System.Data, System.Data.SqlClient then it's pretty much because they are a part of the System.Data.dll assembly, and are an integrated part of it. My own implementation of the IDbCommand etc classes live in MyNamespace.SubNamespace.AdoWrapper namespace, if that gives you some context.
In your case, Simple.Data presumably doesn't exist or have much in it, unlike System.Data ..

Sure it is, if it's semantically correct. Look at how many framework namespaces end in .Design, for example!

It might be confusing to some people, but it should not cause any problems.
You'll probably need to preprend the namespace though if you type this:
using Simple.Odata;
using Simple.Data.Odata;
Otherwise the compile won't recognise it.
There's probably a better structure possible for the thing you're trying to create, but to anwser your question : yes it is ok to do it if you want.

Yes, it is, but there are some drawbacks.
The namespace is part of the type name.
That is, a type named C inside namespace A.B, is actualy named A.B.C.
When you use the using statement, then you are just using a kind of shortcut.
Drawbacks:
I have noticed that sometimes Visual Studio may become little confused, specialy when using namespaces such as System, and others that exist in the .Net framework... in such a way that you must enter the full name of the type.

The last part should be dependant on previous part(s) of the namespace. Your adapter has a dependancy with Simple.OData but also with Simple.Data. But since Simple.OData is less generic I'd prefer something like:
using Simple.Data
namespace Simple.OData.Adapters
{
// The Simple.Data adapter for OData
}

Difference between System.Linq.Dynamic and System.Linq?

Using ReSharper, I occasionally get quick-fix suggestions for importing a namespace for a LINQ operation. So given the following code in a brand-new class:
linqToSqlDataContext.Customers.Count();
I get a quick-fix drop down as follows:
Which should I choose, and what is the difference between them?

System.Linq.Dynamic is the namespace for Dynamic LINQ. You shouldn't be seeing that as an option unless you've added a reference to the Dynamic LINQ assembly though. Have you done so?
You should only do that if you actually want to use Dynamic LINQ.
Dynamic LINQ lets you express queries as text - a bit like with DataTable.Select. I've personally never found a use for it, but you may want it. It should be a deliberate choice though. Most of the time you'll be fine with the statically typed LINQ to Objects.
EDIT: As per the OP's comment, the code for Dynamic LINQ could have been added directly to the project, rather than referenced as a separate assembly. Even if you do actually want to use Dynamic LINQ, I'd strongly recommend keeping it in a separate assembly rather than mixing it in with your own code.

Dynamic LINQ is a non-typesafe version of LINQ. That takes strings rather than lambdas to generate the queries.
Unless you need any of the specialist functionality that this will give you use the Enumerable version instead.

Scott Hanselman did a good explanation of DynamicQueryable. Basically it allows you to have a little more dynamism where the parameters may change during runtime.

Argh! The answer in the end was that one of my colleagues added the DynamicQueryable extensions class to our project (from http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx), and ReSharper was picking that up.

Since I don't see any example of usage of Dynamic LINQ here, here it goes:
In my faculty project I had a situation where I would use Repository pattern to make an abstraction over my used database technology, particulary Entity Framework.
In my Repository I would have a method something like this:
public IEnumerable<T> Find(Expression<Func<T, bool>> predicate);
As you can see, an Expression is used as the predicate.
Also, I had client-server communication over WCF. Since Expressions are not Serializable, I had to use Dynamic LINQ where I would just send string representation of predicates and use them with my Repository.

IList<T> does not have "where"

In a specific project at my work, I have a method that returns IList. But this interface does not contain where, or FindAll filters. However, when I open a new project, IList contains all. What is the difference?

Did you import System.Linq ?

Nope. IEnumerable<T> has "where" as an extension method.
Assuming your project is .Net 3.5 or greater, you need to have using System.Linq;

You might find this useful: LINQ, Where() vs FindAll()

Check .NET Framework of opened framework, may be its .NET Fx 2.
System.Linq added in 3.5

Here's a basic discussion of extension methods in general. As mentioned by others, the Where method is an extension method found in the System.Linq namespace so you need to import it in order to have intellisense detect the existence of those methods.

why is this namespace added by default "System.Collections.Generic"?

Just a general curiosity question. Why is this namespace "System.Collections.Generic" added by default in Visual Studio when we create the project instead of let's say "System.Collections"?
Is Collection Classes under generics is most preferred way than the Collection Classes in the System.Collections?
Thanks
Harsha

Yes, generics collection are better than regular collection because they bring strong typing, which prevent boxing and unboxing, and all those annoying casting.
There are few reason left to use a regular collection. Even if you don't know which type of object that you are storing, you can still use something like List<object>.

Generic collections are far easier to use and it makes sense to me to have them included by default.

.NET 2.0 added generic collections, which should completely replace the use of the non-generic collections in applications built for .NET 2.0 and beyond.
They have many advantages, especially since they bring strong typing and avoid boxing of value types.
As for why the namespace is added by default - I'd guess Microsoft decided to add this to encourage their use instead of the older System.Collections classes.

I suspect that if MS released the .NET BCL with the generic collection classes, many of the non-generic versions would not have been included.
Having said that, there is quite a lot of usage of ArrayList within Microsoft's code.

.NET / C# - Reflection - System.IO.File ever used

Is there a way to use reflection to completely "scan" an assembly to see if System.IO.File or System.IO.Directory is ever used? These are just example classes. Just wondering if there is a way to do it via reflection (vs code analysis).
update:
see comments

As Tommy Carlier suggested, it's very easy to do with Cecil.
using Mono.Cecil;
// ..
var assembly = AssemblyFactory.GetAssembly ("Foo.Bar.dll");
var module = assembly.MainModule;
bool references_file = module.TypeReferences.Contains ("System.IO.File");

The fantastic NDepend tool will give you this sort of dependency information.
Load your dll in NDepend and either use the GUI to find what you want, or the following CQL query:
SELECT TYPES WHERE IsDirectlyUsing "System.IO.File"
and you should get a list of all the types that use this.

I'd suggest looking at Mono Cecil for this. With Cecil, you can enumerate all the classes, methods and even the IL-instructions (including all the methods calls).

I don't remember where, but I found this handy piece of code:
http://gist.github.com/raw/104001/5ed01ea8a3bf7c8ad669d836de48209048d02b96/MethodBaseRocks.cs
It adds an extension method to MethodInfo/ConstructorInfo that parses the ILByteArray into Instruction objects.
So with this, you could loop over every MethodInfo/ConstructorInfo in the assembly, then loop over every Instruction on that MethodInfo/ConstructorInfo, and check if any of those Instruction objects contains an Operand which is an instance of a MemberInfo which has a DeclaringType that is equal to either class.

You can get a list of dependent assemblies via Assembly.GetExecutingAssembly().GetReferencedAssemblies(). I don't believe you can comprehend namespace usage via reflection. Try looking at System.CodeDom. That may help you parse the code.

.NET Reflector can do this, or something close to it. The other day I checked to see where a particular type was used.
ReSharper might also help. I do this with my own symbols all the time - I suppose it would also work for .NET Framework types.