On MSDN I can read what it does, but I would like to know what it does technically (tells compiler where to look for types..)? I mean using as a directive.
The primary function of the using directive is to make types within a namespace available without qualification to the user code. It considers the set of namespaces and types which are defined in referenced assemblies and the project being compiled.
Take for example the following definition in MyTypes.Dll
namespace MyTypes {
class Class1 {}
}
Now consider referencing MyTypes.dll from another project with a different namespace. Without a using directive to create Class1 i need to qualify the name
MyTypes.Class1 local1 = new MyTypes.Class1();
The using directive lets me remove this qualification
using MyTypes;
...
Class1 local1 = new Class1();
#JaredPar's answer is correct, however I'd like to add that it doesn't quite work the same way as say import in Java. (someone correct me if I'm wrong about Java's import actually importing it into memory)
You need to include either a DLL or project reference in order to even be able to use using however it's not loaded into memory until you actually call into a method/property/something in the assembly. So you could have using System.Linq; but if you don't actually use any Linq methods, the Linq assembly is never loaded. (I'm not 100% positive that Linq is in it's own physical assembly since namespaces and assemblies aren't 1:1, but for sake of example I'm assuming it is)
using informs the compiler which namespaces to search for names used in the file but not defined in the file.
using just tell the compiler to go to the assembly's configuration file and search for a specific DLL with the name given, if the DLL is found then it links that dll into the current project. using is just a link operation to have DLL talk to each other in a shared space in memory.
The guy below here is right
Related
I have some older software that I am maintaining. I am attempting to find out what specific reference file contains the namespace that is being brought into the project by the using directive.
Is there a simple way of finding which reference file contains the namespace of a given using directive? This seems like it should be easy, and it probably is, but all of my searching using these terms returns results related to how to implement using directives and reference classes, etc. However, I cannot find an answer for how to find the reference containing the namespace in question.
For some reason, the references often contain namespaces that have nothing to do with the name of the file. For example, I've seen references like Foo.cs that contain the namespace Bar. I then see
using Bar;
and can't find an easy way to see what reference file contains the namespace.
Anyway, apologies in advance if this is something stupidly simple that I'm just not finding.
Object Explorer? It will show the assembly name – Fals
I was able to find the namespace under the type in the object explorer, thank you. Even as a relative beginner, this is something I should have known to try, so thank you for taking the time to point me in the right direction.
I have just looked in my regedit and found I am running .NET Version 4.5.1 and therefore the libraries I am after should be available to me.
I try to include the namespaces:
using System.IO.MemoryStream;
using System.Media.SoundPlayer;
However VS complains that the namespaces do not exist.
The reference pages for MemoryStream and SoundPlayer dictate that these should be available in my version of .NET. How can I fix this?
You are confusing class names and namespaces and possibly the using directive with the using statement.
System.IO is a namespace. It's a grouping construct used to logically group classes and structs together and avoid name clashes. System.IO.MemoryStream is a class inside the System.IO namespace.
If you want to use a MemoryStream you can either:
var ms = new System.IO.MemoryStream(...);
Or, to avoid the verbosity of always specifying the namespace (a full qualified name), you can use the using directive:
using System.IO;
and then you can just use the class name:
var ms = new MemoryStream(...);
You can think of the using directive as telling the compiler what search paths to use when looking for a class. If you ask for MemoryStream it's going to first look in the current namespace for a class named MemoryStream, if it doesn't find one, it's then going to look in all the namespaces that have been imported with the using directive (in VB.NET, I believe the equivalent directive is actually called Imports which, arguably, makes more sense, but there you go). If it still doesn't find a MemoryStream class you'll get a compile time error.
Note: you'll also get a compile time error if it finds more than one MemoryStream because it won't stop on the first one - your classes need to be unambiguous. And this is a reason not to just stuff a lot of unneeded using directives at the top of every .cs file. MemoryStream isn't particularly a problem here (I think it's the only MemoryStream in the BCL), but another class in System.IO is Path. There are several classes called Path in the BCL (There is another one under System.Windows.Shapes) and without namespaces they'd be a nightmare to use.
Now, your confusion might come from the using statement which is often used with classes what implement IDisposable to ensure they get disposed. MemoryStream implement IDisposable so you'll often see things like:
using (var ms = new MemoryStream(...))
{
// some code here
}
Or, if they haven't used the using directive to declare the namespace:
using (var ms = new System.IO.MemoryStream(...))
{
// some code here.
}
Which looks a lot like what you were trying to do with your using directive.
When looking at a class in MSDN there are two important things you need to look for:
Namespace: System.IO
Assemblies: mscorlib (in mscorlib.dll)
System.IO (in System.IO.dll)
Namespace tells you what you need to include either in a using directive or as part of a fully qualified class name in order to use the class. The Assemblies part tells you which assemblies you need to add a references to your projects in order to be able to use those classes. In this case MemoryStream is part of the core libraries, so you aren't likely to not have a reference to the required assemblies.
Just use the namespace only
using System.IO;
using System.Media;
Using System is the right thing to do as MemoryStream is class in itself.
Right Click Project -->Add reference --> Assemblies -->System
Using System.IO
Then in code you can make object of MemoryStream.
I thought I'd add one more point, regarding the format of your using directive. You can use a using directive very nearly like that, in order to create an alias for a namespace or class.
For instance, creating an alias for a class like this:
using SP = System.Media.SoundPlayer;
Allows you to do this:
var sp = new SP();
I was studying for my test today and I came accross the sentence
System.Console.WriteLine();
Could some one tell me what the System stands for cause when I remove it i dont see any diffrence.
System is just the namespace which contains the Console type.
You almost certainly have a using directive like this in your code:
using System;
That imports every type within the namespace, so you can refer to it by its simple name. Without that directive, you would see a difference - System.Console would still work, but just Console wouldn't, because the compiler wouldn't know which type you meant.
The System is the name of the namespace the class Console resides in. You need to give the full name or it won't compile. With one exception: if you have a line using System; on top of your file, whenever something cannot be found, a namespace of System will be assumed for lookup.
System is a Namespace. You will find it in the head of your code.
using System;
If you remove using System;, you will find Console.WriteLine(); can't be complied.
System refers to the main library that contains the fundamental classes that define commonly-used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions. And Console type is one of them.
the reason why you are not getting a difference is that it's referenced by default in the top of your class page
The System in System.Console.WriteLine() refers to the System namespace. Therefore, if you're importing System in your code, it's redundant to call the WriteLine method using that namespace.
http://msdn.microsoft.com/en-us/library/System(v=vs.110).aspx
Just the namespace where Console.WriteLine() resides
which is a default import (using system)
I was under review of team code. I observe they had used class ClassAby writing using AAA.BBB; at the upper portion of the class; also they have sometime used class ClassB by AAA.BBB.ClassB. There are two basic questions.
Is there any performance issue while using above scenario. What is recommended
When I declare namespace; are all classes get loaded of that namespace or not.
Please assist here. Thanks.
I'll answer these as best as I can, I don't have any sources on hand, just experience (maybe someone can help with that).
There is no performance issue with importing a namespace versus calling it directly. When the compiler runs through it, you can think of it as always being fully qualified in the end. The using statement for namespaces is more to assist the developer so they don't have to fully qualify it each time. In fact, for your ClassB example, it could be that there is a collision with multiple namespaces defining the same class name. For example, the Calendar class is both in System.Globalization and System.Web.UI, so you have to fully qualify one or the other when using them.
Generally, all code is compiled into an assembly by the project it's under. Referencing any code inside of the assembly will load all of the associated code. Note, however that the code isn't necessarily compiled for use by the JIT until it's actually called.
Namespaces are for organizing your code (while preventing name collisions). They have no bearing on performance at all.
Fully qualified names in code are distracting and noisy. I prefer to never have them. If there is a namespace conflict, a using alias can resolve that.
only for places where there is a conflict with there being two Class defined in different namespaces, and, even then, I'll still rather use a using to differentiate them:
using MyClassB=AAA.BBB.ClassB;
// :
var myClassB= new MyNS();
in terms of performance, you can see the answer here:
The using directive is only syntactic sugar that disappears during
compilation. Whether or not the namespace was included via using or
mentioned in a fully-qualified type name is totally irrelevant in the
resulting bytecode. Hence, there is no performance benefit at runtime
by using one or the other.
This is such a dumb question, but I can't figure out the lingo to ask Google.
In Java if I wanted to import all subclasses I would use something like
java.util.*
And all of util would be imported.
Firstly, what is the proper lingo for what I'm doing in C# so I can start using Google more effectively. Am I importing namespaces? Libraries? Subclasses? (Can you tell I'm new at this?)
Secondly, since I'm here, how is this accomplished in C#?
PS- I did click on every related question stackOverflow threw at me to see if the answer would pop up. No luck. I'm simply without words to describe what I'm looking for. The example should do just fine but... Anyone who can take a moment to either explain the lingo to me or perhaps simply point me at something that can (in a nutshell, I have a couple books for the long haul) that would be great.
Firstly, let's differentiate between assembly references and namespaces.
Assemblies are what you add references to in your c# project, they are the libraries that contain the actual classes you need, usually found as DLL files. The .net framework contains many such assemblies, and Visual Studio will try to reference the most commonly used ones in your project (e.g. for a WinForms project it will automatically add a reference to System.Drawing.dll).
Namespaces are logical partitions of the classes in an assembly.
Once you reference an assembly in the project, all classes in all namespaces are available for use, if you provide their full name.
This is where the using directive comes in.
It is simply syntactic sugar for not having to write very long names all the time.
For example, assuming your project references the System.Drawing.dll assembly, you would have to qualify a class from this assembly using it's full name, for example
System.Drawing.Imaging.BitmapData
Because this is tiresome and bloats the code, if you start your .cs file with
using System.Drawing.Imaging;
you could then instantiate a class using just the name BitmapData.
This will be true only for the .cs file in which you added the using directive, not for the whole project.
Also, it's important to note that using one namespace does not bring in all nested namespaces, you have to using each one individually.
You must brush up on your your Google-fu
http://www.harding.edu/fmccown/java_csharp_comparison.html#namespaces
It can be called importing / referencing/ using namespace.
Such a language feature is not available in c#.
A little explanation: Namesspaces can be spread across multiple libraries. so when you use a namespace it may refer to it from multiple referenced assemblies.
It's called namespace and it's imported by a keyword using. For example:
using System;
This statement enables you to reference all the classes that exist in that namespace. They, however don't enable you to reference any class in the subnamespace of declared namespace. You have to declare each namespace separately. For example:
using System;
using System.Text;
Of course, you need to have a proper references added to the project where you're specifying the using directive.
Within .Net, you first would need to ensure that there is a referenced assembly containing the namespace you would like to import. Once that reference exists, you can use the 'using' directive to bring that namespace into the class so as to not have to fully qualify all object names. You can find more information on this directive on MSDN.
If I misunderstood, let me know and I'll do my best to get you pointed in the right direction.