References and Using Directives - Page 1
       by kirupa  |  20 July 2008

When you create Silverlight or WPF applications, you can quickly jump in and start writing code. More importantly, you can do that at a fairly high level. You don't have to implement some basic constructs from scratch. The reason you can do this is because a bunch of common classes that you would use have already been created and made available for you out of the box. You can declare objects of type int, string, Storyboard, etc. without really thinking about where those types actually come from, how they were created, etc.

Behind the scenes, there are various DLL files (assemblies) that contain the details of the classes you use. Visual Studio knows which class is stored in which DLL file, and it takes care of everything for you as you are using the classes:

[ Visual Studio makes writing code for recognized classes easy ]

 There are times, though, where this does not work. For example, XDocument in the following example is a valid type supported in Silverlight 2 and .NET 3.0+, yet nothing seems to appear like the above Storyboard case:

[ Visual Studio makes writing code for unrecognized classes hard ]

Your class name is NOT blue colored, which indicates that it is not recognized. There is no auto-complete either. Why is this not working?

The answer seems complicated, but it is fairly simple. Earlier, I mentioned that behind the scenes, various DLL files contain details on all of the classes that you can use in your project. The list of DLL files your project is aware of is fairly limited by default.

If a class is not recognized, such as XDocument in the above example, it means that your project is not aware of the appropriate DLL file that contains the information about the class. To put in more proper terminology, a reference to the assembly containing your XDocument class is missing, and that is why your project is not able to recognize any of the classes that live inside that assembly. When your project has no idea where a class comes from or what it does, you won't get any help inside Visual Studio for using it. In fact, you won't even be able to build your project without getting errors.

There is another twist to this story. Even if a reference exists, your code file needs to know to look at that reference. This is handled by a list of using statements known as using directives, and you can see them at the top of almost every code page:

[ using directives help your code page know what namespace to look into ]

If I haven't confused you entirely with what I just said, then I must have make a mistake. This is a confusing topic to describe, so let me give you a better description of references and using directives before taking you through an example that will hopefully make more sense.

What are References
For every application you create, a set of DLL files (also known as assemblies) are added to your project as a reference. You can view those references by expanding the References folder in the Solution Explorer as shown below:

[ the list of references currently added to your project ]

In the above screenshot, I am working on a Silverlight 2 project, and by default, a Silverlight 2 project contains references to mscorlib, system, System.Core,  System.Net, System.Windows, System.Windows.Browser, and System.XML. Each of these assemblies contain inside them the various types that you can use.

For example, if I declare an object whose type is EventTrigger, the EventTrigger class lives inside the System.Windows assembly. If I wanted to use an XmlReader for some XML parsing, the XmlReader type lives inside System.Xml.

If the assembly reference did not exist, then you would be unable to use that type in your application. That was your problem with the XDocument example I showed earlier. Anyway, more on these details later where I will walk you through an example where you get to add your own reference.

What are Using Directives
A using directive is shorthand for accessing a namespace inside an assembly. This is not to be confused with the other using statement used in conjunction with Disposable objects. The using directives I am referring to are the ones you see at the top of your code:

[ a list of using directives in Page.xaml.cs ]

The best way to describe what makes them useful is via a simple example. The following is what you see when I declare a button object:

Notice that I have an object called foo whose type is Button. Pretty simple. Button, as you can tell by hovering over its type with your mouse, lives in System.Windows.Controls:

If you see a few images earlier where I have all of my using statements displayed, notice that you see a using System.Windows.Controls statement displayed. If I did not have that using statement, the following is how I would actually declare my Button object:

I can no longer get away with just saying Button. I actually have to write out the fully qualified path to our Button class. Using statements provide me with a nice way of taking these common namespaces and placing them in a central location to help my code look cleaner. They do some other things as well, and they will be explained in due time.

Onwards to the next page!

1 | 2 | 3