by
kirupa | 20 July 2008
In the
previous page,
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.
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.
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 page 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. If you have a question and/or want to be part of a friendly, collaborative community of over 220k other developers like yourself, post on the forums for a quick response!
|