We Keep Coding

C# Namespace reserved words

I make the following query, is that I am taking a project which contains a class project with namespace Application.ProyectoA is that now I need to use from a windows project and gives me problems with the proper namespace System.Windows.Application, now try thereby instantiate
_viewModel.Item = global :: Application.ProyectoA.ProyectoManager.Get (200);
I've also tried changing the name of the alias and using external alias, but you can not.
but does not recognize "Application.ProyectoA" anyone has any solution for this, change the namespace cumbersome Original is half as this project is used in several places.
Greetings and thank you very much.

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

How do I make a namespace containing 'System' in .NET without it conflicting?

Sometimes I've made a namespace in C# (I don't know if the problem is the same in VB.NET) containing 'System' and when I include it from a different DLL it goes crazy and conflicts with everything containing 'System'. This leads to crazy errors such as the following :
The type or namespace name
'ServiceModel' does not exist in the
namespace 'RR.System'
The type or namespace name 'Runtime'
does not exist in the namespace
'RR.System'
The type or namespace name
'SerializableAttribute' does not exist
in the namespace 'RR.System'
If you don't know what I'm talking about then good for you :) I'm sure many have seen this issue.
I'm not completely sure why it does this. It will occur even in files, such as generated code for web services that doesn't contain any reference to RR.System.
This all occurs just because I'm including RR.System the DLL in a different project.
How can I avoid this happening? Or fix it?

I still don't see why a child namespace conflicts with a root namespace? All types under a namespace can be fully qualified, and the fully qualified names refer to different types. e.g.
System.Abc.Xyz.Type
has nothing in relation to
Abc.Xyz.System.Type
The System in the first case refers to a completely different concept (The Company name under the guidelines), whereas the System in the second case could refer to the product or subsystem name.
If root namespaces can cause this kind of interference then surely that's a big problem because I may choose to call my new rainforest monitoring product Amazon and put all my types under MyCompany.Amazon. Then later on I may choose to store my data using the S3 storage and suddenly the namespace Amazon causes a conflict.
We've just run into the same issue as our project is split into 3 major sub-systems - Database, User and System. These seem like obvious child namespaces under our MyCompany root namespace.
Remember, this has nothing to do with Using statements as Simon said "It will occur even in files, such as generated code for web services that doesn't contain any reference to RR.System"
UPDATE: The following Stack Overflow question is along the same lines. However the MSDN article it points to discusses a class name called System hiding a namespace (fair enough) and also using System as a top-level namespace (fair enough). However it does not discuss why a child namespace conflicts with a root one.
Stack Overflow Q: Is global:: a bad code smell in C#?
MSDN Article: How to: Use the Namespace Alias Qualifier

Odd.
Now, why are you calling your project "System"?

To avoid confusion, you can fully qualify your namespace references:
global::System.ServiceModel
etc.

There isn't a way to reference both namespaces using the shorthand method. You'll either have to rename your class to prevent the collision, or alias your class like so (which will require you changing your references in your code to use the alias)...
Using System; // The namespace seen and used in all .cs files
Using Sys = RR.System; // Just replace -your- 'System' references with 'Sys'
While this method is legal in C#, it's messy and would suggest renaming your referenced class.

This reminded me of an old joke - Compiler, It hurts when I do this

If you have the option you may want to consider renaming your namespace to something like SystemUtilities or such, or you can just fully qualify all other references which can be a serious pain. Ambiguity with the BCL can lead to some nasty looking code.

If your project contains references to both System and your custom library (RR.System), the compiler will have an ambiguous reference to sort out. It's not sure which one you want.
You can always use aliasing to ensure that your code is explicitly referencing the correct code from your project.
BTW, there's a huge amount of best practice information to follow from Brad Abrams in Framework Design Guidelines.

The namespaces on my companies main projects are broken down to a few levels:
Company.au.ProductName.GUI.*
Company.au.ProductName.Data.*
...
where * would be further broken down depending on function

My company uses Company.Group.Platform.Application.Layer.Component.* It's very annoying and confusing. Needless to say, I use aliases