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.

In the previous section, I gave you a quick overview of references and using directives. Much of what I discussed was very high level and doesn't give you a full picture of either of those two topics. Let's actually look at an example so you can see them both being used.

References and Using Directives in Action

In case you have not done so, create a new Silverlight 2 application using Visual Studio and open Page.xaml.cs. Directly below your InitializeComponent call in the Page constructor, add the following line of code:

XDocument foo = XDocument.Load("</something>");

Your Page constructor should look like the following:

If you press F6 to build your application, you will receive two errors. The errors will essentially state that XDocument is something that Visual Studio currently doesn't recognize, and one of the errors will ask whether you are missing a using directive or assembly reference:

[ building your project will give you an error ]

Hmm....where have you seen those two terms before? Let's get this code working.

Adding a Reference

First, let's add the assembly reference. To add a reference, look in your Solution Explorer, right-click on the References folder, and select Add Reference:

[ right-clicking on your References folder will allow you to add references ]

Once you have done that, the Add Reference window will appear:

[ a list of currently installed .NET components will appear by default ]

The .NET tab should be selected, and that is exactly where we want to be. You should see a list of assemblies displayed, and any of these can be added as a reference to your project. 

In our case, because XDocument is a LINQ-related type, the assembly that contains information about it will be System.XML.Linq. Scroll all the way down until you find the System.XML.Linq entry:

[ add a reference to System.Xml.Linq ]

Once you have found System.Xml.Linq, select it and click on the OK button or just double-click on it to add it as a reference. After a few seconds, you will see your reference to System.Xml.Linq appear in your list of References:

[ your newly added reference now appears in your References folder ]

Great - all that remains is to now setup your using directive.

Adding a Using Directive

Now that your System.Xml.Linq reference has been added to your project, the next step is for your code to be aware of it. There are several ways of doing this, but the easiest way would be to automatically add a using directive.

Look at your code where you see your XDocument object declaration and initialization. Notice that the XDocument type has been underlined in a squiggly blue line:

Right click on any of the squiggly blue lines. A menu will appear, and from this menu, select the Resolve menu-item:

[ the Resolve menu contains the common solutions for you to try ]

The Resolve menu-item expands to display two more sub-items, and notice what these sub-items are. They are shortcuts that will automatically add a using directive for System.Xml.Linq or replace your current XDocument text with the fully qualified System.Xml.Linq.XDocument text.

Go ahead and select the using System.Xml.Linq item to add a using directive instead. Once you have done that (you may need to build your project again), notice that your XDocument text loses its squiggly underline, and it is now colored indicating that it is now recognized by your project. Your using directive is also added to the end of your list of using directives as well:

That's all there is to it!

In the next section, let's talk some more about the using directives and references topics that you may find helpful.

In the previous section, you applied the vague description of using directives and references by looking at a real example. While that should have given you some hands-on experience seeing these two topics in greater detail, there are some interesting tidbits that I did not cover, so let's do that on this page.

Dealing with Naming Conflicts

While not a very common situation, there will be times where you will find that the right combination of referenced assemblies and using directives contain types whose names are not unique.

One example is when you are using the OpenFileDialog class and have both Microsoft.Win32 and System.Windows.Forms types in your project:

Your OpenFileDialog text will be displayed again with the funny blue, squiggly underline. When you press F6 to Build, you will receive an error! The reason for the error can be seen in the Error List:

[ the Error List is a great way to find out what the error means ]

The error is stating that there is some ambiguity in which OpenFileDialog you want to use. Do you want to use the one found in System.Windows.Forms or do you want to use the one found in Microsoft.Win32?

Let's say we just want to use the one found in System.Windows.Forms. To resolve this error, right click on OpenFileDialog in your code, and from the menu that appears, click on the Resolve menu item:

You will see the fully qualified names for OpenFileDialog that you can use. Depending on which you select, your OpenFileDialog text will change to that of your selected name - which in our case will be System.Windows.Forms.OpenFileDialog:

Be sure to do this for all occurrences of OpenFileDialog that you currently have in the code. In my case, I have two such occurrences...both in my declaration as well as initialization.

You probably aren't happy with the extra clutter now in your code. Despite that, this is actually necessary because, while your code looks less elegant, it removes all ambiguity on which OpenFileDialog you really want to use.

If you happen to remove either the System.Windows.Forms or Microsoft.Win32 using directive, you would not have to deal with this problem at all. It is for those rare cases where these conflicts occur, that you will have to trod down this path.

Does Adding Extra References Increase File Size?

Each reference you add usually points to another project or an assembly. In either case, they contain a certain file size themselves. A common question, especially with Silverlight applications, is whether adding references causes the file size of your final output to increase.

The answer to that is yes. Any reference you add, it will get compressed into your XAP if the runtime does not already contain this reference. For example, in the previous section you added a reference to System.Xml.Linq. When I build, my XAP's size is around 60k. When I look into the XAP, notice what I see:

System.Xml.Linq is contained inside your XAP, and it is a whopping 57k in size! Even if I removed the one line of code containing my XDocument object declaration and the System.Xml.Linq using directive, building the project will still produce a XAP whose size is 60k.

Only by actually removing the reference to System.Xml.Linq will the XAP no longer contain the System.Xml.Linq assembly:

---

Just a final word before we wrap up. What you've seen here is freshly baked content without added preservatives, artificial intelligence, ads, and algorithm-driven doodads. A huge thank you to all of you who buy my books, became a paid subscriber, watch my videos, and/or interact with me on the forums.

Your support keeps this site going! 😇