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.

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
}

(Question on best practice) Why is "using System.Text" there by default?

Every time I creat a class, I see using System.Text that is added (amongst other using) by default. Every time I remove it after a while because it is unused according to ReSharper.
Am I missing a best practice? Do you use that namespace often? In which situation?
There has to be a reason why this namespace is referenced by default.
Thanks!

The System.Text namespace contains classes, abstract base classes and helper classes.
Say for example if you wanted to take advantage of the StringBuilder, Decoder, Encoder, etc....
The classes above, plays a significant role in most cases in .net. But it is not necessary for it to be there in your code. It only applies as to when you needed it. The important thing is to know when you will need the namespace.
It is added in visual studio by default for the convenience of the developers. Same with the
System.Linq namespace, not all of the time you will be using it but for your convenience it is already added assuming that you would be using it and that would be up to you to remove it which is by case to case basis.
Sometimes it would be a lot easier to delete it if it is not needed than to figure out the namespace and type when you need it :)
More info regarding System.Text

If it's not being used, it shouldn't be in the code. If Visual Studio adds them by default, chalk that up to Microsoft just trying to make things easy for a developer, as it thinks those are very common namespaces, but depending on what you are doing they likely aren't needed in many classes, just as you experience.

If you don't like it you can always create your own item templates. See http://msdn.microsoft.com/en-us/library/tsyyf0yh(v=VS.80).aspx

You should add using only for those namespaces that you really reference in the code.
This way the source file will not have a huge 'using header' and fewer namespace conflicts.
As you are using Resharper it is very easy to follow this rule.

If you are not using it, don't include the namespace. It is just automatically included because it is one of the more commonly used namespaces. I generally use it if I want to use regular expressions or string manipulation methods. But if you remove it and there are no compiler errors, it is safe to leave it out.

C# - Location of using statements

One thing I have noticed a lot of back and forth on is where using statements should be placed in a C# code file- whether its in the outermost scope or inside a namespace. I understand that the location of the using statement affects the scope of the references within that file, but what I don't understand is why, in most cases, someone would ever want their using statements inside their namespace.
In almost all cases only one namespace declaration ever exists in a single file so scoping the using statements seems/(is?) useless. If one were placing multiple types and multiple namespaces in the same file then scoped using statements make perfect sense, yet I still see plenty of cases of this being done even in files with one namespace. Why?
using System;
namespace MyNamespace
{
using System.Text;
public class MyClass {
// ...
}
}
An example of this being done throughout a project seemingly unnecessarily is the ASP.NET MVC source.

Putting "using" at the top of the files is the default way of Visual Studio. However, the recommended approach is putting the "using" statements inside of the namespace. Even MS's stylecop catches this and says the default way of VS is wrong.
Both techniques work fine.
StyleCop Rule says:
Placing multiple namespace elements
within a single file is generally a
bad idea, but if and when this is
done, it is a good idea to place all
using directives within each of the
namespace elements, rather than
globally at the top of the file. This
will scope the namespaces tightly, and
will also help to avoid the kind of
behavior described above.
It is important to note that when code
has been written with using directives
placed outside of the namespace, care
should be taken when moving these
directives within the namespace, to
ensure that this is not changing the
semantics of the code. As explained
above, placing using-alias directives
within the namespace element allows
the compiler to choose between
conflicting types in ways that will
not happen when the directives are
placed outside of the namespace.
Here's some links for further review:
Should 'using' statements be inside or outside the namespace?
Is sa1200 All using directives must be placed inside the namespace (StyleCop) purely cosmetic?
http://www.hanselman.com/blog/BackToBasicsDoNamespaceUsingDirectivesAffectAssemblyLoading.aspx
http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmustbeplacedwithinnamespace.aspx

I'd never even seen/heard of this practice until I started using StyleCop and would get flagged by rule SA1200, which I now just disable. It's odd that the .cs files that Visual Studio creates as part of a new project violate this rule by placing the using directives at the very beginning of the file, outside of the namespace.

edited, with my head hanging in shame
Ahh! The using statement you're refering to is used to import a namespace, not to wrap an IDisposable object!
Very different, ambiguous terms... you had me confused :-)
Personally I like them outside the namespace at the top of the file; but it's probably due to me switching between C# and VB.NET.
I like to organize my projects into 1-file-per-class, no inner (nested) classes, and only one class per namespace (per file) . In this situation the location of the using statement is irrelevant whether inside or outside the namespace.
The iDesign C# coding standard is a solid standard to follow (or to derive your own from). It recommends keeping the using statements outside the namespace as item #14. But it's all down to your company / project's convention

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