tags:

views:

385

answers:

9

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?

+6  A: 

Odd.

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

Justice
because its shared utilities for the application/system
Simon_Weaver
Then better to go with [YourCompanyName]System. Namespaces are there for a reason :-)
Learning
System means .NET Framework System. You may want another name like "MyProduct.Framework" or "MyProduct.Core" ....
Justice
To be fair, the examples have shown that the namespace is "RR.System" which is more reasonable. However, I'd suggest "RR.Common" as a less problematic name.
Jon Skeet
+3  A: 

To avoid confusion, you can fully qualify your namespace references:

global::System.ServiceModel

etc.

Cheeso
A: 

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.

Quintin Robinson
A: 

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.

jro
A: 

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

benPearce
+1  A: 

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.

invenetix
I suggest RR is a better alias than Sys.
Dour High Arch
Agreed. Or using 'RRSys' even.
invenetix
+1  A: 

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

Bedwyr Humphreys
A: 

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

tsilb
+2  A: 

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 casues 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

Chris Oldwood
@chris i think this is one of those cases that actually fishing around for real MSDN documentation might actually help in understanding the subtleties
Simon_Weaver