We Keep Coding

Namespace Shadowing Class Name

I have the following situation:
A compiled library with the namespace Library which contains class Feauture.
Now there is another library in development, one which intends to utilize the feature, and that has been dubbed Library.Feature. Finally there is a third library: Library.Feature.UI.
When working in the Library.Feature.UI project, which has both other libraries referenced, VS is yelling a lot about trying to using the Feature class, because it is seeing it primarily as a namespace.
I've tried a few different using directives to get around this, as well as trying to qualify the class name, but nothing is working.
Assuming I don't have the ability to change any of the namespaces or existing class names, is there a way to circumvent this issue?

You can either use fully qualified names where you specify the namespace together with the type name or you can use a using directive to create an alias:
using MyFeature = Library.Feature;

You can use alias directives to give a different name to any namespace, and then use that alias to reference that namespace.
By doing this you can differentiate between the class and the namespace.
write the following on top while using namespaces.
using FeatureClass = Library.Feature;
For more knowledge on this, you can refer:
https://msdn.microsoft.com/en-us/library/aa664765%28v=vs.71%29.aspx
Let me know if you have any further issue...

This should do the trick (references)
using FeatureClass = Library.Feature;

System.Linq.Queryable is not an attribute class error?

I am getting an error when adding [Queryable] the error is similar like this 'System.Linq.Queryable' is not an attribute class
when I tried to add namespace before [System.Web.Http.Queryable] I got another error
The type System.Web.Http.QueryableAttribute exists in both
System.Web.Http.OData.dll and System.Web.Http.dll
How to resolve this?

As Soner Gönül said.
Most probably you have
two using directives in your cs file:
using System.Web;
using System.Web.Http;
both define the attribute. Either remove one of those namespaces or fully qualify your attribute either as
[System.Web.Queryable]
// or
[System.Web.Http.Queryable]
Depending what the difference is of both and what you need. You will find more help in the corresponding MSDN documentation of both.

You have two DLL references that contain exactly the same namespace, containing a class with exactly the same name. The simplest solution is to remove one of these references from your project. If you need them both for some other reasons then the only solution I can think of is to create another project which will wrap the classes you need within other classes in a different namespace.

basic question on C# - do I need a namespace?

I am a Java developer, totally new to C#. I am currently writing a DLL for distribution across my organization. It is a very simple library containing a couple of classes and I do not see any real use in putting all of them into some namespace just for the sake of it. Do I really have to use a namespace? If so, why? Is it some kind of a best practice?

Do you need one? No. Should you have one? Yes. It'll help prevent clashes with identically named classes in other namespaces without having to resort to the (IMHO) ugly use of global::.

For throwaway test apps (e.g. checking Stack Overflow answers), I don't use a namespace. For anything else, I do. It's just an organization thing - if you're going to reuse code, it's helpful to separate it from other code you're also reusing in the same context. What I mean is, if you're creating an app using LibraryX and LibraryY, it's useful to be able to differentiate between them within the app. It's possible that they both use the same class names, for example - which will make the code ugly if you don't use namespaces.
Aside from anything else, if you're coding with Visual Studio it's actually more work not to include a namespace - you've got to modify the project to give it an empty default namespace.

There is no need to have a namespace. However developer studio expects you to be using a name space. For example, when you choose to add a class to a project developer studio will:
Create a file for the class
Add the file to the project
Create an empty class (in the above file) that is in the project’s default namespace.
A “project’s default namespace” is a developer studio concept not a C# concept and is set in the properties of the project.
As you are creating a dll for others to use, it will be a lot easier for the users of your dll if you have a name space:
People expect you to have a namespace (so may be confused if you don’t)
Namespaces make it a lot easier for your users if you have class (or enum etc) that is named the same as another class in any dll they are linking to.
Therefore I don’t see a good reason not to use a namespace.

My vote for "yes" i think it is good habit to use namespace. you can not be sure that people won't use same class names.

To respond to your comment about naming a class the same as it's namespace, read a little bit of the following article.
Short version: don't do that.
http://blogs.msdn.com/b/ericlippert/archive/2010/03/09/do-not-name-a-class-the-same-as-its-namespace-part-one.aspx

Basically System is a root namespace in asp.net C#.
In .net every programs is create with a default name space. This default namespace is called global name space. But program itself create any numbers of namespace, each of unique name.
learn more
http://asp-net-by-parijat.blogspot.in/2015/08/what-is-namespace-in-c-need-of.html

C# class in a directory without having the directory name in its namespace

If you add a directory in your Visual Studio project and you add a class inside it, the namespace will respect the whole path the directory inclusive.
But sometimes, I prefer having the class in the main project namespace, although it lies in a directory structure, just because I don't want to have mess in my code.
So often happens that I rewrite the Myproject.MyDirectory namespace to be Myproject only.
Is it OK in your opinion? Or does any convention say that every class inside the directory must have it included in the namespace ?
Thanks

There isn't any convention restricting from what you're trying to do. I usually have multiple directories in my project to organize class files and use different namespaces with no respect to the directory structure and I don't have any problems.

In my view, folders and namespaces serve for different purposes.
Folders are useful to provide a clear hierarchy for people who read your code
Namespaces are useful to provide a clear hierarchy for people who use your code. E.g. calling the API provided by your code, when they don't see the actual source code.
Therefore, inconsistency is perfectly fine, as long as each makes sense.

There is no constraint, but some think it's useful to have the namespace identical to the path. So you could choose any namespace and place the class file wherever you want.

Properly assigning Namespaces (with ReSharper's suggestions)

Lets say we have the following file and [folder] structure in a project with a main namespace of MyNamespace:
[Entities]
Article.cs
Category.cs
[Interfaces]
IReviewable.cs
ISearchable.cs
Enumerations.cs
According to ReSharper's suggestions, the namespace of the classes Article and Category should be MyNamespace.Entities, the namespace of IReviewable and ISearchable should be MyNamespace.Interfaces and the namespace for the Enumerations class should be simply MyNamespace.
This is because ReSharper's suggestions are based on the folder structure depending and its suggestions are based on where th file is located in the structure.
What do you think of the above namespaces? Do you think that it is correct to implement namespaces for classes (interfaces etc...) solely on their folder location?
Or do you think that namespace declaration shouldn't depend solely on the folder structure?
Personally, I would put all the above files under the single MyNamespace since they are all kind-of related to one another.

I think ReSharper's suggestions are fine. I think it's a mistake to group classes, etc., by what they are instead of what they do.
An analogy is grouping documents in subfolders Word, Excel, etc. instead of by Project or some other functional grouping.

Note that ReSharper adds a "Namespace Provider" property to each folder in your project. You can set that property to false for a folder that you want to use for organization, but to not contribute to namespaces.

It is a good practice to organize files in meaningful folders and build up namespace from that structure. Java has been following that rule for many years and it works out to be good.
Also note that when you have a lot of sub namespaces as above, it is time to consider levelizing as suggested by Patrick (well, you know him?)
http://codebetter.com/blogs/patricksmacchia/archive/2009/02/15/re-factoring-re-structuring-and-the-cost-of-levelizing.aspx