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();
Related
When adding a new class into a namespace this is what I get (this is in an mvc3 project)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
namespace Foo.Models
{
public class Bar
{
}
}
In the namespace Foo.Models there are other classes. However, it is nice to separate content by placing them in different .cs locations. I think that is fairly standard. I know the compiler works its magic to compose all these later anyway. Which is kind of where my question arose from. If the namespace is composed later on, then why is there a requirement to always be redefining what the class is using? If it is already available somewhere in the namespace, then should it be necessary to say using System; in every .cs file defining a class inside of the namespace? Can someone explain this a little for me, and also perhaps shed some light on a possible way to do implement this in a way where I define all of the using cases for a namespace once and then any classes added to that namespace inherently have access to those.
The using statements are scoped to the particular .cs file you are working with.
They simply provide a convenient shortcut in the context of that class file that allows you to use the names of classes only, rather than fully qualifying class names everywhere you use them.
Namespaces exist because different teams will inevitably use the same class name for different classes (I wonder how many Util classes are out there).
You may have two different classes in your project that want to use different objects with the same name. The ability to have different using statements in each file lets you do that conveniently.
Note that you can always edit the template for new classes to pre-populate the using statements you need in all of your classes.
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)
I'm (very) new to C#, and I need to know how to import classes.
In Java, I could just say:
package com.test;
class Test {}
And then in some other class:
package com.test2;
import com.test.Test;
How could I do this in C#?
Importing namespaces is accomplished in C# with the using directive:
using com.test;
However, there is no way, currently, to import a class. Importing classes, however is a new feature which is being introduced in C# 6 (which will come with Visual Studio 2015).
In C#, namespaces are the semi-equivalent of Java's packages. To declare the namespace, you just need to do something like this:
namespace com.test
{
class Test {}
}
If the class is declared in a separate assembly (such as a class library), simply adding the using directive is not enough. You must also add a reference to the other assembly.
I don't come from a Java background, but I come from a Python, C/C++ background where I always used something like "import" or "#include" and it always felt pretty simple.
But I want to share what I have learned so that others after me don't have to go through the same confusion. To give an example, I am going to show how to create a SHA256 instance.
using System.Security.Cryptography; //this is the namespace, which is what you import; this will be near the top of documentation you read
using static System.Security.Cryptography.SHA256; //this is an additional class inside the namespace that you can use; this will be in the "derived" section of documentation
AlgorithmHash sha = SHA256.Create(); //I am not entirely sure why, but the declaration needs to be on the same line as the instantiation
I have attached the HashAlgorithm documentation for reference: https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.hashalgorithm?view=net-5.0.
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.
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