Sorry if this question was asked already.
I started studying C# and noticed that C# doesn't automatically import nested namespaces.
I don't understand:
using System;
should automatically import all classes contained in the System namespace right?
So there should be no need for me to write
using System.Windows.Form;
I would understand if using Windows.Form even worked. But the compiler could not resolve it! What is the point of the using System; before it then?
So why does using System; not import System.Windows automatically as well as System.Windows.Forms - sorry if the word import is wrong here.. maybe move to global namespace is the right terminology.
C# is not Java.
A using directive is used so you don't have to type in the fully qualified name of a type. It also helps with disambiguating type names (using aliases for instance).
In the case of Console, for example, you don't need to type System.Console.
It is important to understand the difference between a namespace and an assembly - a namespace is a logical grouping of types. An assembly is a physical grouping of types. Namespaces can span assemblies.
When you reference an assembly (this is more like importing a package in Java), you gain access to all of the public types in it. In order to use a type you need to uniquely identify it. This is done through the namespace - the using directive simply means you don't have to type the fully qualified name of the type.
The using directive has two uses:
To allow the use of types in a namespace so that you do not have to
qualify the use of a type in that namespace:
using System.Text;
To create an alias for a namespace or a type. This
is called a using alias directive.
using Project = PC.MyCompany.Project;
http://msdn.microsoft.com/en-us/library/sf0df423.aspx
However, you have to note that System and System.Windows.Form are not connected through name itself in anyway. If you import (using) System that means you will use the System assembly types in this class. Actual reference you specify in references section in Visual Studio project which you can really use (even without using statement, as this is just a shortcut for types).
C# doesn't import nested namespaces and this is by design.
Namespace scope lets you organize code and gives you a way to create
globally unique types.
Nested namespaces are used to group related functionality, but use parts of it on-demand.
I guess you wouldn't want to have all the types from such a big namespace like System if the only thing you need is System.Windows.
So probably the question is why C# doesn't have something like using System.*; like java does. I don't know the answer, but I guess this is because of KISS principle. It's something like using
select *
you will never know what types you will add and how they will affect existing code.
Even in Java you'd have to explicitly write
import System.*;
Much of the time you don't want all of the nested namespaces. These would simply clutter IntelliSense.
The "using" syntax allows you shorthand access to namespaces that are already listed as References in the project settings. If the namespace is listed as a reference you already have access to it by it's full name without the "using" directive. Just saves keystrokes.
"Using" a given namespace means that you will get access to all definitions implemented directly in it, not that it will recursively look up the embedded namespaces; doing otherwise would defeat the purpose of the "Using" statement.
Namespaces exist to avoid class name ambiguity. The "Using" statement is here to avoid the use of fully qualified types nested in namespaces, when you know no (or little) ambiguity may occur.
No, this is not how it works.
And I will give a good argument against what you said: intellisnse would go crazy and finding the what you want would be hell.
You do have access to everything on every namespace available (with dots), the using keyword simplifies this because you don't have to specify from which namespace a class or struct is "coming from" (I mean, defined).
Related
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;
This question already has answers here:
Using Statements vs Namespace path? C#
(6 answers)
Closed 8 years ago.
I want to use Console.WriteLine method. There are two ways
using System; and then Console.WriteLine(); this is one way
System.Console.WriteLine(). this is another way
What is the difference between these two?
Will all the classes include under system namespace if i use using System; ?
Will console class only include when i use System.Console.WriteLine statement?
using System is just a syntactic sugar that allows you to access all the classes under the namespace without specifying the namespace. So yes, using System imports all the classes that are defined in System namespace then you can access them by their name.
In case where you include two namespaces that has two identical class then you will have to use fully-qualified name of the class to avoid ambiguity.
Also it is worth noting that this is just a shortcut. The using directive doesn't add anything to your project.So if you need to use a class or a function from a third-party dll, first you have to add a reference to your assembly (*.dll file) then you can use using directive.
using System;
<CODEHERE>
<CODEHERE>
Console.WriteLine("Text");
<CODEHERE>
<CODEHERE>
This is the more generic, and usual way of doing it for two reasons:
It is more readable
And if you wanted to use another class of System, you would already have the import.
Using the other method:
System.Console.WriteLine("Text");
is a lot more rare to see, and you would have to write out the fully qualified name of any other System class, or just to use it again:
System.Console.WriteLine("Text");
System.Console.WriteLine("Text2");
If you look back at what the using statement actualy means:
'Using' is a statement used to stop the programmer from repeatedly having to type the fully qualified namespace for everything.
I would use the 'using System' version.
This question already has answers here:
Importing nested namespaces automatically in C#
(7 answers)
Closed 9 years ago.
so my program has these 2 lines at the beginning
using System;
using System.IO;
Question: Is the second statement actually necessary to include Sytem.IO methods and properties in my code?
It seems that 'System.IO' is a 'child' of the namespace 'System'. Shouldn't the first line grab all the child namespaces too? Or Do I not understand namespaces correctly?
System.IO namespace is used for Input Output operations.(Ex: File Operations)
System namespace does not include all child namespaces.
So if you want to perform IO Operations you should include System.IO namespace explicitly.
First Question : Is the second statement actually necessary to
include Sytem.IO methods and properties in my code?
Yes it is Necessary as System namespace does not include Child namespaces.
Second Question : It seems that 'System.IO' is a 'child' of the
namespace 'System'.
Yes System.IO is a Child of System namespace.
Note : though System.IO is a child namspace of System, it will not be included when you include System namspace
Third Question : Shouldn't the first line grab all the child
namespaces too? Or Do I not understand namespaces correctly?
No first line using System; does not grab all the Child namespaces as it is not java to import all child namspeaces using wild card character star *
C# is not like java, where you can use wildcards to import namespaces.
using System;
in C# is not the same as
import system.*;
in Java.
And that's really all there is to it. You need to explicitly include namespaces - not much more to say about it :)
Shouldn't the first line grab all the child namespaces too? Or Do I not understand namespaces correctly?
No - it will only make an alias for types in the System namespace directly. "Nested" namespaces (such as System.IO) are not made aliases automatically in C#. This is mentioned in the help for the using directive (italics added by me for emphasis):
allow the use of types in a namespace so that you do not have to qualify the use of a type in that namespace
You would still need to qualify IO for IO operations. For example, if you wanted to use the Path class, you'd need:
var filename = System.IO.Path.GetFilename(fullPath);
To expand on the other answers, there really aren't "child namespaces". There's nothing stopping you from declaring your own System.IO. You wouldn't want to of course, but you don't need a parent System namespace to do it.
You may have a project that by default has MyCompany.MyProject namespace, but you could just as easily declare XYZ.Some.Other.Random.Namespace in another .cs file of the same project. There's no inheritance to namespaces and XYZ.Some.Other doesn't exist. C# will let you use it, however, when you try to instantiate your class using the rest of it (Random.Namespace), it doesn't know how to find the class and won't resolve until you fully qualify the namespace in the using or fully qualify your variable declaration.
The first statement of all my C# files is "using System;".
Now with framework version 4 this namespace contains a class called "Action". This is also the name for a class im my own code in a regularly used namespace. Now there is of course a conflict. Ofcourse I can resolve this conflict by using explicit "MyNamespace.Action" where ever I was using "Action" before. This are several hundreds if not thousands of lines. Or I could not use the System namespace, which of course leads to many other problems. I would like to write something like "using System but not System.Action", but I cannot find a statement to do this.
Any ideas?
No, you can't.
But you can add using Action = MyNamespace.Action. This will be highly confusing for new developers, though, as Action is a fundamental part of .net since 3.5 so I strongly suggest you rename your class.
The using directive has two uses:
To permit the use of types in a namespace so you do not have to qualify the use of a type in that namespace:
using System.Text;
To create an alias for a namespace or a type (you could go for this one).
using Project = PC.MyCompany.Project;
The using keyword can also be used to create using statements, which define when an object will be disposed. See using statement for more information.
using directive (C# Reference)
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