Hi Adam,
First, let me make sure you understand the difference between a DLL, a
NameSpace, and a Class, since you like to toss references to DLLs about, and
DLLs are not part of a running application. A DLL is a file. It contains
code that is loaded into System memory when the application starts. It is
not directly used by the application. The code (classes, etc) from the DLL
is loaded into memory, and from there you have the actual NameSpaces,
classes, etc., that your application uses. At this point it is best to think
of these things as objects or things, rather than as code, as that is how
they behave.
A NameSpace is a logical container, or identifier. You might think of a
NameSpace as, for example, a country, or a state in a country. It has a
name, and contains other things. But other than that, it has no
functionality. It is used by an object-oriented program to uniquely identify
the things inside it. For example, there is a city in Pennsylvania named
"Philadelph ia." There is also a city named "Philadelph ia" in Tennessee. So,
if I were to tell you that I was going to travel to Philadelpphia, you could
not logically determine what city I was going to. The name of the city would
be ambiguous. But if I were to tell you that I was going to Philadelphia,
Pennsylvania, you would know for sure which Philadelphia I was going to be
in.
A class is like a business in a city. It has functionality. It does things.
It has properties, such as Employees, a number of products that it produces,
it's income, profit, etc. The class is identified, as a business is
identified, by its address. So, let's say you were in Philadelphia,
Pennsylvania, and you wanted to go to City Hall to obtain a license. City
Hall is like a business, but I'm using a reference to a business for which
there is only one instance in any city as an example to make things simpler
and clearer. So, you're in Philadelphia, Pennsylvania and you're going to go
to City Hall. You want your friend to meet you there, so you tell her "Meet
me at City Hall." Of course, there is a City Hall in every city, but you're
already in a city, so you don't have to tell her "I'm going to City Hall,
Phildelphia, Pennsylvania." You just have to say "City Hall." But what if
you were outside a city, in a county somewhere in the same state? You would
then have to say "I'm going to the Philadelphia City Hall." Or, if you were
outside the country, and you wanted her to meet you in City Hall in
Philadelphia, Pennsylvania, you would have to use the full address. In fact,
you might also have to use the country name. So, in this illustration,
"Pennsylvan ia" and "Philadelph ia" are like NameSpaces. They are simply used
for addressing, or identifying. If you had an application with a NameSpace
of "Pennsylvan ia" containing a NameSpace of "Philadelph ia," and in that
NameSpace a class named "CityHall," you would refer to it as
"Pennsylvania.P hiladelphia.Cit yHall."
And .Net has one more twist in store for you. The same NameSpace can exist
in multiple DLLs. Although this is generally not the right way to do things,
there are situations in which it IS the right way to do things, for purposes
of optimization. That is, when you load a DLL, you load the ENTIRE DLL into
memory, into what is called "the heap." So, while some classes might all
logically seem to belong in the same parent NameSpace, there can be
situations in which certain types of apps might not need a bunch of them,
and it would therefore waste memory to load them at run-time. I have seen
this in several (nut thankfully not many) of the .Net CLR dlls. Still, it is
important to remember, and not assume that because 2 classes or NameSpaces
are in different DLLs that they are not in the same parent NameSpace. Using
Geography again as an illustration, think of the U.S., in which 49 states
are in the same continent. But of course, there are 50 states. Hawaii is not
in the North American continent. But it is in the "NameSpace" of the U.S.
Finally, a Class is a NameSpace, but it is not quite the same as a
NameSpace. That is, a Class is a logical container, which can contain other
Classes, structures, enumerations, but also Fields, Properties, Constants,
Methods, etc. A NameSpace doesn't have to be a Class. Unless it is defined
as a Class, it is not a Class. But a Class is always a NameSpace. In other
words, a Class is a special type of NameSpace, which has all of the
object-oriented properties of a Class.
Okay, you've got a C# DLL, and the name of it, I will guess, is
"Engine.Dll ." Now, C# is different from VB.Net in the way that it compiles
projects. In VB.Net, the default NameSpace for a DLL is the name of the DLL.
You can change it, but it is assigned automatically as the NameSpace unless
you do. In C#, you must assign a NameSpace yourself. So, the "Engine.DLL "
could contain any NameSpace as its top-level container. You need to find out
what it is if you want to use it in your app. If using Visual Studio.Net,
the Class View Pane will show you, as will the Object Browser (and of
course, Intellisense).
Your app also uses a Global.asax source code file. This compiles to a class
called "Global," which resides in your app's DLL's root NameSpace, whatever
it is. Note that this NameSpace will (almost certainly) be different than
the Engine.DLL's root NameSpace. However, I'm not sure if that is what
you're referring to, as you mentioned a source code file named "global.cs. "
But, if you want to learn more about the Global class that is compiled from
the global.asax file, see
http://odetocode.com/Articles/89.aspx.
For now, I will assume that the "global.cs" source code file is a different
source code file. Note that I have not referred to any class yet, as a
source code file is NOT part of your app, but is used to compile your app.
In fact, the name of the source code file doesn't necessarily have any
relationship with any of the classes contained therein, and there may be
more than one class, enumeration, and/or structure defined in it.
Since you didn't mention the name of the class that contains the
"GetRegions ()" method (only the name of the source code file), I can't even
assume that it is indeed contained in a class named "Globals." For now, I
will make that working assumption. Assuming that it is, you need to identify
the NameSpace of the class in which it resides. It is (almost certainly) not
in the "Engine" NameSpace.
Hopefully, this should help clear things up. Remember:
DLLs are not part of your application, which resides in memory at run-time
A DLL can contain more than one NameSpace
NameSpaces are logical containers used to identify the "address" of the
items inside them
NameSpaces can reside in more than one DLL
NameSpaces can be contained in other NameSpaces
Classes reside in NameSpaces
Classes ARE NameSpaces, but a special type of NameSpace
Source Code files are not part of your application, but used to create it
A Source Code file can contain multiple NameSpaces and Classes
A Property, Field, or Method is uniquely identified by its NameSpace
hierarchy
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Adam" <Ad**@discussio ns.microsoft.co m> wrote in message
news:7E******** *************** ***********@mic rosoft.com...
Thank you for your reply.. Very informative.
The Engine is a C#.dll, Global is the global.cs file and GetRegion is :
public static void GetRegions(Syst em.Web.UI.WebCo ntrols.DropDown List
regionList, string selectedValue)
I will look at the other information you supplied and you know what we
come
up with.
Thanks,
Adam
"Kevin Spencer" wrote:
You have several object references in that statement. Your job is to
figure
out which one is Nothing, and why. Let's identify them:
Engine.Globals. GetRegions(Me.S tate, String.Empty)
"Engine" is the first possible object reference. However, as you say it's
the name of a VB.Net DLL, it would have to be a NameSpace reference,
which
is not an object, but a perfectly legal part of an object reference.
"Globals" would be the second possible object reference. As you are
calling
a method via "Globals," I would say that this is very probably indeed an
object (an instance of a class) or a class. If it is not an instance of a
class, you could not call a method from it unless that method was a
Shared
(static) method. Otherwise you would indeed get a NullReferenceEx ception,
because you didn't have an instance of the Globals class. The only way
"Globals" could be an instance of a class is if "Engine" was either an
instance of a class or a class with a Shared "Globals" instance in it.
But
as you have identified "Engine" as a NameSpace, "Globals" would not be an
instance of a class, but an uninstantiated class. So, if "GetRegions ()"
is
not a shared method, there is your exception.
But let's imagine that (it is perfectly possible) "GetRegions ()" is a
Shared
method, and that "Globals" is a class that is not instantiated, in the
"Engine" namespace. In that case, we have 1 other possibility to examine.
If
"Me.State" is Nothing (null), this would then throw the
NullReferenceEx ception. String.Empty is an empty string (""), so it would
not.
So, you should now have all the information you need to determine the
cause
of your exception.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Adam" <Ad**@discussio ns.microsoft.co m> wrote in message
news:9B******** *************** ***********@mic rosoft.com... > We have a web site that uses .vb for the web pages and .cs for a class
> module. We are getting the error in .NET 2.0 and VS 2005 beta 2. It
> does
> work with .NET 1.1.
>
> When trying to access a page that needs the class module I get an error
> on
> web site:
>
> Object reference not set to an instance of an object
>
> Here is where the error is:
>
> Engine.Globals. GetRegions(Me.S tate, String.Empty)
>
> Under the stack Trace:
> [NullReferenceEx ception: Object reference not set to an instance of an
> object.]
> and a bunch of other code :)
>
> Engine is the name of the dll and yes it is being referenced in the
> project.
>
> Any help would be great!!
>
> Thanks,
> Adam