473,326 Members | 2,196 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Namespaces - broad question

I'm confused about the proper use and usefulness of namespaces. I beleive I
understand the purpose is so the developer can put classes within namespaces
to essentially organize your code. And I understand that you declare your
intention to use a namespace within a page through the "Inherits" attribute.
I know that using "Inherits" isn't absolutely necessary, it's just
recommended so the developer doesn't have to type out the entire namespace
in code. I know that namespaces have to appear in the project assembly,
however...

How does the assembly find a namespace that the developer has written????
In all the examples I've seen, namespaces have been written in codebehind
pages. How does this make them accessible to the entire project? What's to
prevent a duplicate namespace from being written in a different codebehind
page? Is there a better place to write all the project namespaces for more
centralized accessibility?

And finally, how do namespaces DIFFER from classes?

Random
Nov 18 '05 #1
22 1133
First of all, namespaces can be used with the 'Imports' keyword, so as not
have to write out the full namespace for every class, not the 'Inherits'
attribute.

Think of namespaces as folders in your file system, and classes as the files
in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files.
Classes are the actual things that you instantiate, and call methods on.

I didn't really understand your questions. I think they all stem from not
understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
I'm confused about the proper use and usefulness of namespaces. I beleive I understand the purpose is so the developer can put classes within namespaces to essentially organize your code. And I understand that you declare your
intention to use a namespace within a page through the "Inherits" attribute. I know that using "Inherits" isn't absolutely necessary, it's just
recommended so the developer doesn't have to type out the entire namespace
in code. I know that namespaces have to appear in the project assembly,
however...

How does the assembly find a namespace that the developer has written????
In all the examples I've seen, namespaces have been written in codebehind
pages. How does this make them accessible to the entire project? What's to prevent a duplicate namespace from being written in a different codebehind
page? Is there a better place to write all the project namespaces for more centralized accessibility?

And finally, how do namespaces DIFFER from classes?

Random

Nov 18 '05 #2
First of all, namespaces can be used with the 'Imports' keyword, so as not
have to write out the full namespace for every class, not the 'Inherits'
attribute.

Think of namespaces as folders in your file system, and classes as the files
in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files.
Classes are the actual things that you instantiate, and call methods on.

I didn't really understand your questions. I think they all stem from not
understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
I'm confused about the proper use and usefulness of namespaces. I beleive I understand the purpose is so the developer can put classes within namespaces to essentially organize your code. And I understand that you declare your
intention to use a namespace within a page through the "Inherits" attribute. I know that using "Inherits" isn't absolutely necessary, it's just
recommended so the developer doesn't have to type out the entire namespace
in code. I know that namespaces have to appear in the project assembly,
however...

How does the assembly find a namespace that the developer has written????
In all the examples I've seen, namespaces have been written in codebehind
pages. How does this make them accessible to the entire project? What's to prevent a duplicate namespace from being written in a different codebehind
page? Is there a better place to write all the project namespaces for more centralized accessibility?

And finally, how do namespaces DIFFER from classes?

Random

Nov 18 '05 #3
Hmm. I'm trying to teach myself from examples and tutorials and books.
Specifically in this case, I'm trying to learn from the MS PortalStarterKit.
Specifically, the default page in that example has as the first line in
default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb" AutoEventWireup="false"
Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's
more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes
it's way into the assembly. And because it does, somehow, does that make it
available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all, namespaces can be used with the 'Imports' keyword, so as not
have to write out the full namespace for every class, not the 'Inherits'
attribute.

Think of namespaces as folders in your file system, and classes as the files in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files.
Classes are the actual things that you instantiate, and call methods on.

I didn't really understand your questions. I think they all stem from not
understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
I'm confused about the proper use and usefulness of namespaces. I beleive
I
understand the purpose is so the developer can put classes within namespaces
to essentially organize your code. And I understand that you declare

your intention to use a namespace within a page through the "Inherits"

attribute.
I know that using "Inherits" isn't absolutely necessary, it's just
recommended so the developer doesn't have to type out the entire namespace in code. I know that namespaces have to appear in the project assembly,
however...

How does the assembly find a namespace that the developer has written???? In all the examples I've seen, namespaces have been written in codebehind pages. How does this make them accessible to the entire project? What's to
prevent a duplicate namespace from being written in a different

codebehind page? Is there a better place to write all the project namespaces for

more
centralized accessibility?

And finally, how do namespaces DIFFER from classes?

Random


Nov 18 '05 #4
Hmm. I'm trying to teach myself from examples and tutorials and books.
Specifically in this case, I'm trying to learn from the MS PortalStarterKit.
Specifically, the default page in that example has as the first line in
default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb" AutoEventWireup="false"
Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's
more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes
it's way into the assembly. And because it does, somehow, does that make it
available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all, namespaces can be used with the 'Imports' keyword, so as not
have to write out the full namespace for every class, not the 'Inherits'
attribute.

Think of namespaces as folders in your file system, and classes as the files in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files.
Classes are the actual things that you instantiate, and call methods on.

I didn't really understand your questions. I think they all stem from not
understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
I'm confused about the proper use and usefulness of namespaces. I beleive
I
understand the purpose is so the developer can put classes within namespaces
to essentially organize your code. And I understand that you declare

your intention to use a namespace within a page through the "Inherits"

attribute.
I know that using "Inherits" isn't absolutely necessary, it's just
recommended so the developer doesn't have to type out the entire namespace in code. I know that namespaces have to appear in the project assembly,
however...

How does the assembly find a namespace that the developer has written???? In all the examples I've seen, namespaces have been written in codebehind pages. How does this make them accessible to the entire project? What's to
prevent a duplicate namespace from being written in a different

codebehind page? Is there a better place to write all the project namespaces for

more
centralized accessibility?

And finally, how do namespaces DIFFER from classes?

Random


Nov 18 '05 #5
This inherits attribute, refers to the name of the class this page inherits
from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.

At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available. It is
just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
Hmm. I'm trying to teach myself from examples and tutorials and books.
Specifically in this case, I'm trying to learn from the MS PortalStarterKit. Specifically, the default page in that example has as the first line in
default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb" AutoEventWireup="false" Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's
more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes
it's way into the assembly. And because it does, somehow, does that make it available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all, namespaces can be used with the 'Imports' keyword, so as not
have to write out the full namespace for every class, not the 'Inherits'
attribute.

Think of namespaces as folders in your file system, and classes as the

files
in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files.
Classes are the actual things that you instantiate, and call methods on.

I didn't really understand your questions. I think they all stem from not understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
I'm confused about the proper use and usefulness of namespaces. I

beleive
I
understand the purpose is so the developer can put classes within

namespaces
to essentially organize your code. And I understand that you declare

your intention to use a namespace within a page through the "Inherits"

attribute.
I know that using "Inherits" isn't absolutely necessary, it's just
recommended so the developer doesn't have to type out the entire namespace in code. I know that namespaces have to appear in the project assembly, however...

How does the assembly find a namespace that the developer has written???? In all the examples I've seen, namespaces have been written in codebehind pages. How does this make them accessible to the entire project? What's
to
prevent a duplicate namespace from being written in a different

codebehind page? Is there a better place to write all the project namespaces for

more
centralized accessibility?

And finally, how do namespaces DIFFER from classes?

Random



Nov 18 '05 #6
This inherits attribute, refers to the name of the class this page inherits
from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.

At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available. It is
just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
Hmm. I'm trying to teach myself from examples and tutorials and books.
Specifically in this case, I'm trying to learn from the MS PortalStarterKit. Specifically, the default page in that example has as the first line in
default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb" AutoEventWireup="false" Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's
more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes
it's way into the assembly. And because it does, somehow, does that make it available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all, namespaces can be used with the 'Imports' keyword, so as not
have to write out the full namespace for every class, not the 'Inherits'
attribute.

Think of namespaces as folders in your file system, and classes as the

files
in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files.
Classes are the actual things that you instantiate, and call methods on.

I didn't really understand your questions. I think they all stem from not understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
I'm confused about the proper use and usefulness of namespaces. I

beleive
I
understand the purpose is so the developer can put classes within

namespaces
to essentially organize your code. And I understand that you declare

your intention to use a namespace within a page through the "Inherits"

attribute.
I know that using "Inherits" isn't absolutely necessary, it's just
recommended so the developer doesn't have to type out the entire namespace in code. I know that namespaces have to appear in the project assembly, however...

How does the assembly find a namespace that the developer has written???? In all the examples I've seen, namespaces have been written in codebehind pages. How does this make them accessible to the entire project? What's
to
prevent a duplicate namespace from being written in a different

codebehind page? Is there a better place to write all the project namespaces for

more
centralized accessibility?

And finally, how do namespaces DIFFER from classes?

Random



Nov 18 '05 #7
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me give
you an example...

Using the portal code I gave before, would I be able to write another aspx
page, use the same "Inherits=<fully qualified class name>" phrasing, without
that class being written into the different codebehind page referenced in
the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally referenced
file?

If no, then how can the assembly keep track of all the declared namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
This inherits attribute, refers to the name of the class this page inherits from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.
At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available. It is
just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
Hmm. I'm trying to teach myself from examples and tutorials and books.
Specifically in this case, I'm trying to learn from the MS PortalStarterKit.
Specifically, the default page in that example has as the first line in
default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb"

AutoEventWireup="false"
Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's
more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes it's way into the assembly. And because it does, somehow, does that make it
available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all, namespaces can be used with the 'Imports' keyword, so as

not have to write out the full namespace for every class, not the 'Inherits' attribute.

Think of namespaces as folders in your file system, and classes as the

files
in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files. Classes are the actual things that you instantiate, and call methods on.
I didn't really understand your questions. I think they all stem from not understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
> I'm confused about the proper use and usefulness of namespaces. I

beleive
I
> understand the purpose is so the developer can put classes within
namespaces
> to essentially organize your code. And I understand that you declare your
> intention to use a namespace within a page through the "Inherits"
attribute.
> I know that using "Inherits" isn't absolutely necessary, it's just
> recommended so the developer doesn't have to type out the entire

namespace
> in code. I know that namespaces have to appear in the project assembly, > however...
>
> How does the assembly find a namespace that the developer has

written????
> In all the examples I've seen, namespaces have been written in

codebehind
> pages. How does this make them accessible to the entire project?

What's
to
> prevent a duplicate namespace from being written in a different

codebehind
> page? Is there a better place to write all the project namespaces

for more
> centralized accessibility?
>
> And finally, how do namespaces DIFFER from classes?
>
> Random
>
>



Nov 18 '05 #8
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me give
you an example...

Using the portal code I gave before, would I be able to write another aspx
page, use the same "Inherits=<fully qualified class name>" phrasing, without
that class being written into the different codebehind page referenced in
the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally referenced
file?

If no, then how can the assembly keep track of all the declared namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
This inherits attribute, refers to the name of the class this page inherits from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.
At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available. It is
just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
Hmm. I'm trying to teach myself from examples and tutorials and books.
Specifically in this case, I'm trying to learn from the MS PortalStarterKit.
Specifically, the default page in that example has as the first line in
default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb"

AutoEventWireup="false"
Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's
more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes it's way into the assembly. And because it does, somehow, does that make it
available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all, namespaces can be used with the 'Imports' keyword, so as

not have to write out the full namespace for every class, not the 'Inherits' attribute.

Think of namespaces as folders in your file system, and classes as the

files
in them. So a namespace itself isn't anything but an organizational
container for classes - just as a folder is just a container for files. Classes are the actual things that you instantiate, and call methods on.
I didn't really understand your questions. I think they all stem from not understanding what a namespace actually is.

"Random" <ci*******@hotmail.com> wrote in message
news:uD**************@TK2MSFTNGP10.phx.gbl...
> I'm confused about the proper use and usefulness of namespaces. I

beleive
I
> understand the purpose is so the developer can put classes within
namespaces
> to essentially organize your code. And I understand that you declare your
> intention to use a namespace within a page through the "Inherits"
attribute.
> I know that using "Inherits" isn't absolutely necessary, it's just
> recommended so the developer doesn't have to type out the entire

namespace
> in code. I know that namespaces have to appear in the project assembly, > however...
>
> How does the assembly find a namespace that the developer has

written????
> In all the examples I've seen, namespaces have been written in

codebehind
> pages. How does this make them accessible to the entire project?

What's
to
> prevent a duplicate namespace from being written in a different

codebehind
> page? Is there a better place to write all the project namespaces

for more
> centralized accessibility?
>
> And finally, how do namespaces DIFFER from classes?
>
> Random
>
>



Nov 18 '05 #9
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have no
idea what you are talking about when you ask about namespaces being written
in central locations.

You can have any number of pages inherit from the same class - as long as
that class actually exists. In the visual studio model, you would have to
manually do that, because it assume a 1 to 1 ration between pages and code
behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like
you are missing some basic concept about how this all works. In your first
post you asked about the difference between a namespace and a class - so it
seems like you need to go to the beginning of .NET, and not just into the
middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me give you an example...

Using the portal code I gave before, would I be able to write another aspx
page, use the same "Inherits=<fully qualified class name>" phrasing, without that class being written into the different codebehind page referenced in
the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally referenced file?

If no, then how can the assembly keep track of all the declared namespaces? And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
This inherits attribute, refers to the name of the class this page

inherits
from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed

it.

At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available. It is
just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
Hmm. I'm trying to teach myself from examples and tutorials and books. Specifically in this case, I'm trying to learn from the MS

PortalStarterKit.
Specifically, the default page in that example has as the first line in default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb"

AutoEventWireup="false"
Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes it's way into the assembly. And because it does, somehow, does that make
it
available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
> First of all, namespaces can be used with the 'Imports' keyword, so as not
> have to write out the full namespace for every class, not the 'Inherits' > attribute.
>
> Think of namespaces as folders in your file system, and classes as
the files
> in them. So a namespace itself isn't anything but an organizational
> container for classes - just as a folder is just a container for

files. > Classes are the actual things that you instantiate, and call methods on. >
> I didn't really understand your questions. I think they all stem
from not
> understanding what a namespace actually is.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:uD**************@TK2MSFTNGP10.phx.gbl...
> > I'm confused about the proper use and usefulness of namespaces. I
beleive
> I
> > understand the purpose is so the developer can put classes within
> namespaces
> > to essentially organize your code. And I understand that you

declare your
> > intention to use a namespace within a page through the "Inherits"
> attribute.
> > I know that using "Inherits" isn't absolutely necessary, it's just
> > recommended so the developer doesn't have to type out the entire
namespace
> > in code. I know that namespaces have to appear in the project

assembly,
> > however...
> >
> > How does the assembly find a namespace that the developer has
written????
> > In all the examples I've seen, namespaces have been written in
codebehind
> > pages. How does this make them accessible to the entire project?
What's
> to
> > prevent a duplicate namespace from being written in a different
codebehind
> > page? Is there a better place to write all the project namespaces for > more
> > centralized accessibility?
> >
> > And finally, how do namespaces DIFFER from classes?
> >
> > Random
> >
> >
>
>



Nov 18 '05 #10
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have no
idea what you are talking about when you ask about namespaces being written
in central locations.

You can have any number of pages inherit from the same class - as long as
that class actually exists. In the visual studio model, you would have to
manually do that, because it assume a 1 to 1 ration between pages and code
behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like
you are missing some basic concept about how this all works. In your first
post you asked about the difference between a namespace and a class - so it
seems like you need to go to the beginning of .NET, and not just into the
middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me give you an example...

Using the portal code I gave before, would I be able to write another aspx
page, use the same "Inherits=<fully qualified class name>" phrasing, without that class being written into the different codebehind page referenced in
the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally referenced file?

If no, then how can the assembly keep track of all the declared namespaces? And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
This inherits attribute, refers to the name of the class this page

inherits
from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed

it.

At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available. It is
just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
Hmm. I'm trying to teach myself from examples and tutorials and books. Specifically in this case, I'm trying to learn from the MS

PortalStarterKit.
Specifically, the default page in that example has as the first line in default.aspx:

<%@ Page CodeBehind="Default.aspx.vb" language="vb"

AutoEventWireup="false"
Inherits="ASPNET.StarterKit.Portal.CDefault" %>

The codebehind page has:

Namespace ASPNET.StarterKit.Portal
Public Class CDefault
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
<code here>
End Sub
End Class
End Namespace

I'm trying to find out how and why this works the way that it does. It's more complex than the examples given by tutorials and books.

And again, I'm trying to figure out how the namespace declared here makes it's way into the assembly. And because it does, somehow, does that make
it
available through the entire project?

Random

"Marina" <so*****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
> First of all, namespaces can be used with the 'Imports' keyword, so as not
> have to write out the full namespace for every class, not the 'Inherits' > attribute.
>
> Think of namespaces as folders in your file system, and classes as
the files
> in them. So a namespace itself isn't anything but an organizational
> container for classes - just as a folder is just a container for

files. > Classes are the actual things that you instantiate, and call methods on. >
> I didn't really understand your questions. I think they all stem
from not
> understanding what a namespace actually is.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:uD**************@TK2MSFTNGP10.phx.gbl...
> > I'm confused about the proper use and usefulness of namespaces. I
beleive
> I
> > understand the purpose is so the developer can put classes within
> namespaces
> > to essentially organize your code. And I understand that you

declare your
> > intention to use a namespace within a page through the "Inherits"
> attribute.
> > I know that using "Inherits" isn't absolutely necessary, it's just
> > recommended so the developer doesn't have to type out the entire
namespace
> > in code. I know that namespaces have to appear in the project

assembly,
> > however...
> >
> > How does the assembly find a namespace that the developer has
written????
> > In all the examples I've seen, namespaces have been written in
codebehind
> > pages. How does this make them accessible to the entire project?
What's
> to
> > prevent a duplicate namespace from being written in a different
codebehind
> > page? Is there a better place to write all the project namespaces for > more
> > centralized accessibility?
> >
> > And finally, how do namespaces DIFFER from classes?
> >
> > Random
> >
> >
>
>



Nov 18 '05 #11
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am
disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am trying
to clarify here. I thought that by asking 'basic' questions, I might get a
better understanding of how things fit into the whole. So please be patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it can
be centrally referenced?

You are right, I think there is something very simple I am misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have no idea what you are talking about when you ask about namespaces being written in central locations.

You can have any number of pages inherit from the same class - as long as
that class actually exists. In the visual studio model, you would have to
manually do that, because it assume a 1 to 1 ration between pages and code
behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly itself knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like
you are missing some basic concept about how this all works. In your first post you asked about the difference between a namespace and a class - so it seems like you need to go to the beginning of .NET, and not just into the
middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me give
you an example...

Using the portal code I gave before, would I be able to write another aspx
page, use the same "Inherits=<fully qualified class name>" phrasing,

without
that class being written into the different codebehind page referenced in the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally

referenced
file?

If no, then how can the assembly keep track of all the declared

namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
This inherits attribute, refers to the name of the class this page

inherits
from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed
it.

At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available.
It is just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
> Hmm. I'm trying to teach myself from examples and tutorials and books. > Specifically in this case, I'm trying to learn from the MS
PortalStarterKit.
> Specifically, the default page in that example has as the first line in > default.aspx:
>
> <%@ Page CodeBehind="Default.aspx.vb" language="vb"
AutoEventWireup="false"
> Inherits="ASPNET.StarterKit.Portal.CDefault" %>
>
> The codebehind page has:
>
> Namespace ASPNET.StarterKit.Portal
> Public Class CDefault
> Inherits System.Web.UI.Page
> Private Sub Page_Load(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles MyBase.Load
> <code here>
> End Sub
> End Class
> End Namespace
>
> I'm trying to find out how and why this works the way that it does. It's
> more complex than the examples given by tutorials and books.
>
> And again, I'm trying to figure out how the namespace declared here

makes
> it's way into the assembly. And because it does, somehow, does that

make
it
> available through the entire project?
>
> Random
>
> "Marina" <so*****@nospam.com> wrote in message
> news:%2****************@TK2MSFTNGP09.phx.gbl...
> > First of all, namespaces can be used with the 'Imports' keyword,
so as not
> > have to write out the full namespace for every class, not the

'Inherits'
> > attribute.
> >
> > Think of namespaces as folders in your file system, and classes as the > files
> > in them. So a namespace itself isn't anything but an
organizational > > container for classes - just as a folder is just a container for

files.
> > Classes are the actual things that you instantiate, and call methods on.
> >
> > I didn't really understand your questions. I think they all stem from not
> > understanding what a namespace actually is.
> >
> > "Random" <ci*******@hotmail.com> wrote in message
> > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > I'm confused about the proper use and usefulness of namespaces.

I > beleive
> > I
> > > understand the purpose is so the developer can put classes within > > namespaces
> > > to essentially organize your code. And I understand that you

declare
> your
> > > intention to use a namespace within a page through the "Inherits" > > attribute.
> > > I know that using "Inherits" isn't absolutely necessary, it's just > > > recommended so the developer doesn't have to type out the entire
> namespace
> > > in code. I know that namespaces have to appear in the project
assembly,
> > > however...
> > >
> > > How does the assembly find a namespace that the developer has
> written????
> > > In all the examples I've seen, namespaces have been written in
> codebehind
> > > pages. How does this make them accessible to the entire project? > What's
> > to
> > > prevent a duplicate namespace from being written in a different
> codebehind
> > > page? Is there a better place to write all the project

namespaces for
> > more
> > > centralized accessibility?
> > >
> > > And finally, how do namespaces DIFFER from classes?
> > >
> > > Random
> > >
> > >
> >
> >
>
>



Nov 18 '05 #12
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am
disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am trying
to clarify here. I thought that by asking 'basic' questions, I might get a
better understanding of how things fit into the whole. So please be patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it can
be centrally referenced?

You are right, I think there is something very simple I am misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have no idea what you are talking about when you ask about namespaces being written in central locations.

You can have any number of pages inherit from the same class - as long as
that class actually exists. In the visual studio model, you would have to
manually do that, because it assume a 1 to 1 ration between pages and code
behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly itself knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like
you are missing some basic concept about how this all works. In your first post you asked about the difference between a namespace and a class - so it seems like you need to go to the beginning of .NET, and not just into the
middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me give
you an example...

Using the portal code I gave before, would I be able to write another aspx
page, use the same "Inherits=<fully qualified class name>" phrasing,

without
that class being written into the different codebehind page referenced in the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally

referenced
file?

If no, then how can the assembly keep track of all the declared

namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
This inherits attribute, refers to the name of the class this page

inherits
from. The class's name is CDefault, but it is located in the
ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed
it.

At runtime, asp.net looks for a class with the name in the inherits
attribute.

This has nothing to do with projects, or namespaces being available.
It is just the fully qualified name of the class.

"Random" <ci*******@hotmail.com> wrote in message
news:OI*************@TK2MSFTNGP09.phx.gbl...
> Hmm. I'm trying to teach myself from examples and tutorials and books. > Specifically in this case, I'm trying to learn from the MS
PortalStarterKit.
> Specifically, the default page in that example has as the first line in > default.aspx:
>
> <%@ Page CodeBehind="Default.aspx.vb" language="vb"
AutoEventWireup="false"
> Inherits="ASPNET.StarterKit.Portal.CDefault" %>
>
> The codebehind page has:
>
> Namespace ASPNET.StarterKit.Portal
> Public Class CDefault
> Inherits System.Web.UI.Page
> Private Sub Page_Load(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles MyBase.Load
> <code here>
> End Sub
> End Class
> End Namespace
>
> I'm trying to find out how and why this works the way that it does. It's
> more complex than the examples given by tutorials and books.
>
> And again, I'm trying to figure out how the namespace declared here

makes
> it's way into the assembly. And because it does, somehow, does that

make
it
> available through the entire project?
>
> Random
>
> "Marina" <so*****@nospam.com> wrote in message
> news:%2****************@TK2MSFTNGP09.phx.gbl...
> > First of all, namespaces can be used with the 'Imports' keyword,
so as not
> > have to write out the full namespace for every class, not the

'Inherits'
> > attribute.
> >
> > Think of namespaces as folders in your file system, and classes as the > files
> > in them. So a namespace itself isn't anything but an
organizational > > container for classes - just as a folder is just a container for

files.
> > Classes are the actual things that you instantiate, and call methods on.
> >
> > I didn't really understand your questions. I think they all stem from not
> > understanding what a namespace actually is.
> >
> > "Random" <ci*******@hotmail.com> wrote in message
> > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > I'm confused about the proper use and usefulness of namespaces.

I > beleive
> > I
> > > understand the purpose is so the developer can put classes within > > namespaces
> > > to essentially organize your code. And I understand that you

declare
> your
> > > intention to use a namespace within a page through the "Inherits" > > attribute.
> > > I know that using "Inherits" isn't absolutely necessary, it's just > > > recommended so the developer doesn't have to type out the entire
> namespace
> > > in code. I know that namespaces have to appear in the project
assembly,
> > > however...
> > >
> > > How does the assembly find a namespace that the developer has
> written????
> > > In all the examples I've seen, namespaces have been written in
> codebehind
> > > pages. How does this make them accessible to the entire project? > What's
> > to
> > > prevent a duplicate namespace from being written in a different
> codebehind
> > > page? Is there a better place to write all the project

namespaces for
> > more
> > > centralized accessibility?
> > >
> > > And finally, how do namespaces DIFFER from classes?
> > >
> > > Random
> > >
> > >
> >
> >
>
>



Nov 18 '05 #13
My point was about the understandings of .NET, not your experience with
anything else. I think if the distinction between what a namespace is, and
what a class is, is unclear, then you can't really go anywhere until it is.

When VS.NEt compiles your web project, it places all the classes in one DLL.
When a page is requested, the class in this Inherits attribute is looked for
in the bin directory - so it has to be compiled into one of the DLL's that
is located in that directory. This is done by the asp.net process at run
time - nothing to do with visual studio. Visual studio doesn't keep track
of anything - it just compiles all the classes in the project into one
assembly. If there are duplicate class names, then the compilation process
will fail.

I am still not understanding what you think is being kept track of and
where. Or what you ask when you talk about keeping the code in .vb and .cs
files - the source is already in those files. What does "what if I wrote an
aspx page that inherited a class contained in a codebehind page that was NOT
referenced by the aspx page?" mean? How can you write a page that inherits
from a codebehind class - but yet not reference it?

Do you have a book that you are reading about this from, that is not
explaining it well?
"Random" <ci*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am trying to clarify here. I thought that by asking 'basic' questions, I might get a better understanding of how things fit into the whole. So please be patient with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know where to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't it make more sense to put all the code into a *.vb or *.cs file where it can be centrally referenced?

You are right, I think there is something very simple I am misunderstanding, but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being written
in central locations.

You can have any number of pages inherit from the same class - as long as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so

it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me
give
you an example...

Using the portal code I gave before, would I be able to write another aspx page, use the same "Inherits=<fully qualified class name>" phrasing,

without
that class being written into the different codebehind page referenced in the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally

referenced
file?

If no, then how can the assembly keep track of all the declared

namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
> This inherits attribute, refers to the name of the class this page
inherits
> from. The class's name is CDefault, but it is located in the
> ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.
>
> At runtime, asp.net looks for a class with the name in the inherits
> attribute.
>
> This has nothing to do with projects, or namespaces being available. It
is
> just the fully qualified name of the class.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:OI*************@TK2MSFTNGP09.phx.gbl...
> > Hmm. I'm trying to teach myself from examples and tutorials and

books.
> > Specifically in this case, I'm trying to learn from the MS
> PortalStarterKit.
> > Specifically, the default page in that example has as the first

line in
> > default.aspx:
> >
> > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> AutoEventWireup="false"
> > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> >
> > The codebehind page has:
> >
> > Namespace ASPNET.StarterKit.Portal
> > Public Class CDefault
> > Inherits System.Web.UI.Page
> > Private Sub Page_Load(ByVal sender As System.Object, ByVal
e As
> > System.EventArgs) Handles MyBase.Load
> > <code here>
> > End Sub
> > End Class
> > End Namespace
> >
> > I'm trying to find out how and why this works the way that it
does. It's
> > more complex than the examples given by tutorials and books.
> >
> > And again, I'm trying to figure out how the namespace declared here makes
> > it's way into the assembly. And because it does, somehow, does that make
> it
> > available through the entire project?
> >
> > Random
> >
> > "Marina" <so*****@nospam.com> wrote in message
> > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > First of all, namespaces can be used with the 'Imports' keyword,

so
as
> not
> > > have to write out the full namespace for every class, not the
'Inherits'
> > > attribute.
> > >
> > > Think of namespaces as folders in your file system, and classes as the
> > files
> > > in them. So a namespace itself isn't anything but an

organizational > > > container for classes - just as a folder is just a container for
files.
> > > Classes are the actual things that you instantiate, and call methods on.
> > >
> > > I didn't really understand your questions. I think they all stem

from
> not
> > > understanding what a namespace actually is.
> > >
> > > "Random" <ci*******@hotmail.com> wrote in message
> > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > I'm confused about the proper use and usefulness of
namespaces. I > > beleive
> > > I
> > > > understand the purpose is so the developer can put classes within > > > namespaces
> > > > to essentially organize your code. And I understand that you
declare
> > your
> > > > intention to use a namespace within a page through the "Inherits" > > > attribute.
> > > > I know that using "Inherits" isn't absolutely necessary, it's just > > > > recommended so the developer doesn't have to type out the
entire > > namespace
> > > > in code. I know that namespaces have to appear in the project
> assembly,
> > > > however...
> > > >
> > > > How does the assembly find a namespace that the developer has
> > written????
> > > > In all the examples I've seen, namespaces have been written in
> > codebehind
> > > > pages. How does this make them accessible to the entire

project? > > What's
> > > to
> > > > prevent a duplicate namespace from being written in a different > > codebehind
> > > > page? Is there a better place to write all the project namespaces for
> > > more
> > > > centralized accessibility?
> > > >
> > > > And finally, how do namespaces DIFFER from classes?
> > > >
> > > > Random
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #14
My point was about the understandings of .NET, not your experience with
anything else. I think if the distinction between what a namespace is, and
what a class is, is unclear, then you can't really go anywhere until it is.

When VS.NEt compiles your web project, it places all the classes in one DLL.
When a page is requested, the class in this Inherits attribute is looked for
in the bin directory - so it has to be compiled into one of the DLL's that
is located in that directory. This is done by the asp.net process at run
time - nothing to do with visual studio. Visual studio doesn't keep track
of anything - it just compiles all the classes in the project into one
assembly. If there are duplicate class names, then the compilation process
will fail.

I am still not understanding what you think is being kept track of and
where. Or what you ask when you talk about keeping the code in .vb and .cs
files - the source is already in those files. What does "what if I wrote an
aspx page that inherited a class contained in a codebehind page that was NOT
referenced by the aspx page?" mean? How can you write a page that inherits
from a codebehind class - but yet not reference it?

Do you have a book that you are reading about this from, that is not
explaining it well?
"Random" <ci*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am trying to clarify here. I thought that by asking 'basic' questions, I might get a better understanding of how things fit into the whole. So please be patient with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know where to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't it make more sense to put all the code into a *.vb or *.cs file where it can be centrally referenced?

You are right, I think there is something very simple I am misunderstanding, but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being written
in central locations.

You can have any number of pages inherit from the same class - as long as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so

it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me
give
you an example...

Using the portal code I gave before, would I be able to write another aspx page, use the same "Inherits=<fully qualified class name>" phrasing,

without
that class being written into the different codebehind page referenced in the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally

referenced
file?

If no, then how can the assembly keep track of all the declared

namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
> This inherits attribute, refers to the name of the class this page
inherits
> from. The class's name is CDefault, but it is located in the
> ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.
>
> At runtime, asp.net looks for a class with the name in the inherits
> attribute.
>
> This has nothing to do with projects, or namespaces being available. It
is
> just the fully qualified name of the class.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:OI*************@TK2MSFTNGP09.phx.gbl...
> > Hmm. I'm trying to teach myself from examples and tutorials and

books.
> > Specifically in this case, I'm trying to learn from the MS
> PortalStarterKit.
> > Specifically, the default page in that example has as the first

line in
> > default.aspx:
> >
> > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> AutoEventWireup="false"
> > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> >
> > The codebehind page has:
> >
> > Namespace ASPNET.StarterKit.Portal
> > Public Class CDefault
> > Inherits System.Web.UI.Page
> > Private Sub Page_Load(ByVal sender As System.Object, ByVal
e As
> > System.EventArgs) Handles MyBase.Load
> > <code here>
> > End Sub
> > End Class
> > End Namespace
> >
> > I'm trying to find out how and why this works the way that it
does. It's
> > more complex than the examples given by tutorials and books.
> >
> > And again, I'm trying to figure out how the namespace declared here makes
> > it's way into the assembly. And because it does, somehow, does that make
> it
> > available through the entire project?
> >
> > Random
> >
> > "Marina" <so*****@nospam.com> wrote in message
> > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > First of all, namespaces can be used with the 'Imports' keyword,

so
as
> not
> > > have to write out the full namespace for every class, not the
'Inherits'
> > > attribute.
> > >
> > > Think of namespaces as folders in your file system, and classes as the
> > files
> > > in them. So a namespace itself isn't anything but an

organizational > > > container for classes - just as a folder is just a container for
files.
> > > Classes are the actual things that you instantiate, and call methods on.
> > >
> > > I didn't really understand your questions. I think they all stem

from
> not
> > > understanding what a namespace actually is.
> > >
> > > "Random" <ci*******@hotmail.com> wrote in message
> > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > I'm confused about the proper use and usefulness of
namespaces. I > > beleive
> > > I
> > > > understand the purpose is so the developer can put classes within > > > namespaces
> > > > to essentially organize your code. And I understand that you
declare
> > your
> > > > intention to use a namespace within a page through the "Inherits" > > > attribute.
> > > > I know that using "Inherits" isn't absolutely necessary, it's just > > > > recommended so the developer doesn't have to type out the
entire > > namespace
> > > > in code. I know that namespaces have to appear in the project
> assembly,
> > > > however...
> > > >
> > > > How does the assembly find a namespace that the developer has
> > written????
> > > > In all the examples I've seen, namespaces have been written in
> > codebehind
> > > > pages. How does this make them accessible to the entire

project? > > What's
> > > to
> > > > prevent a duplicate namespace from being written in a different > > codebehind
> > > > page? Is there a better place to write all the project namespaces for
> > > more
> > > > centralized accessibility?
> > > >
> > > > And finally, how do namespaces DIFFER from classes?
> > > >
> > > > Random
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #15
Hi Random,
I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?
A .Net assembly is a compiled DLL. The data in the code files is compiled
into binary code in the DLL, including all the namespace information,
references, etc. Once compiled into a DLL, your CodeBehind class files are
nothing but dead weight. They are not used; the DLL is. So, forget about the
"written classes". Think about the classes themselves, rather than the code
you write to create them.
As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
You wouldn't be able to compile OR use it. An aspx Page is a composite of 2
distinct entities: the Page Template (.aspx) and the CodeBehind class. The
Page Template inherits the CodeBehind class, which inherits
System.Web.UI.Page. The .aspx file by itself can do nothing without
CodeBehind, whether that is in the same (.aspx) file as the Page Template, a
CodeBehind file, or a DLL. The important thing is that the .aspx Page
Template has a reference in it telling it where to look for the class
definition that it inherits. If the CodeBehind is compiled into a DLL, and
that DLL is in one of the locations that ASP.Net can find it (Global
Assembly Cache or \bin folder), ASP.Net uses Reflection to query the
assembly for the class, based upon the NameSpace and Class name of the
class. All of this information is contained in the DLL itself.
Since the class is found in the assembly, how would the aspx page know where to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't it make more sense to put all the code into a *.vb or *.cs file where it can be centrally referenced?
Again, only the CodeBehind is compiled. The Page Template (.aspx) must have
a Reference in it telling it where to find the CodeBehind class. There IS
not "central source" for information about .Net classes. That is why you can
simply put your DLLs into the \bin folder of your web app, and they will be
found. Once found, the .Net platform can query the DLLs to find the DLL
needed, and the class inside the DLL to use.

Take a look at the following example, from an ASPX page I created:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="WebForm1.aspx.vb" Inherits="ControlTest.WebForm1"%>

The "CodeBehind" attribute is there solely for the benefit of Visual
Studio.Net. It tells VS.Net what file to compile to create the DLL used by
the Page class(es). The "Inherits" directive is the key. Note that it
contains no information about the location of the DLL. ASP.Net KNOWS where
the DLL can be located. Instead, it contains a reference to a NameSpace and
a class, which it can find by using Reflection on the assemblies in the \bin
folder and the GAC.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#D**************@TK2MSFTNGP10.phx.gbl... I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am trying to clarify here. I thought that by asking 'basic' questions, I might get a better understanding of how things fit into the whole. So please be patient with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know where to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't it make more sense to put all the code into a *.vb or *.cs file where it can be centrally referenced?

You are right, I think there is something very simple I am misunderstanding, but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being written
in central locations.

You can have any number of pages inherit from the same class - as long as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so

it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me
give
you an example...

Using the portal code I gave before, would I be able to write another aspx page, use the same "Inherits=<fully qualified class name>" phrasing,

without
that class being written into the different codebehind page referenced in the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally

referenced
file?

If no, then how can the assembly keep track of all the declared

namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
> This inherits attribute, refers to the name of the class this page
inherits
> from. The class's name is CDefault, but it is located in the
> ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.
>
> At runtime, asp.net looks for a class with the name in the inherits
> attribute.
>
> This has nothing to do with projects, or namespaces being available. It
is
> just the fully qualified name of the class.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:OI*************@TK2MSFTNGP09.phx.gbl...
> > Hmm. I'm trying to teach myself from examples and tutorials and

books.
> > Specifically in this case, I'm trying to learn from the MS
> PortalStarterKit.
> > Specifically, the default page in that example has as the first

line in
> > default.aspx:
> >
> > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> AutoEventWireup="false"
> > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> >
> > The codebehind page has:
> >
> > Namespace ASPNET.StarterKit.Portal
> > Public Class CDefault
> > Inherits System.Web.UI.Page
> > Private Sub Page_Load(ByVal sender As System.Object, ByVal
e As
> > System.EventArgs) Handles MyBase.Load
> > <code here>
> > End Sub
> > End Class
> > End Namespace
> >
> > I'm trying to find out how and why this works the way that it
does. It's
> > more complex than the examples given by tutorials and books.
> >
> > And again, I'm trying to figure out how the namespace declared here makes
> > it's way into the assembly. And because it does, somehow, does that make
> it
> > available through the entire project?
> >
> > Random
> >
> > "Marina" <so*****@nospam.com> wrote in message
> > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > First of all, namespaces can be used with the 'Imports' keyword,

so
as
> not
> > > have to write out the full namespace for every class, not the
'Inherits'
> > > attribute.
> > >
> > > Think of namespaces as folders in your file system, and classes as the
> > files
> > > in them. So a namespace itself isn't anything but an

organizational > > > container for classes - just as a folder is just a container for
files.
> > > Classes are the actual things that you instantiate, and call methods on.
> > >
> > > I didn't really understand your questions. I think they all stem

from
> not
> > > understanding what a namespace actually is.
> > >
> > > "Random" <ci*******@hotmail.com> wrote in message
> > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > I'm confused about the proper use and usefulness of
namespaces. I > > beleive
> > > I
> > > > understand the purpose is so the developer can put classes within > > > namespaces
> > > > to essentially organize your code. And I understand that you
declare
> > your
> > > > intention to use a namespace within a page through the "Inherits" > > > attribute.
> > > > I know that using "Inherits" isn't absolutely necessary, it's just > > > > recommended so the developer doesn't have to type out the
entire > > namespace
> > > > in code. I know that namespaces have to appear in the project
> assembly,
> > > > however...
> > > >
> > > > How does the assembly find a namespace that the developer has
> > written????
> > > > In all the examples I've seen, namespaces have been written in
> > codebehind
> > > > pages. How does this make them accessible to the entire

project? > > What's
> > > to
> > > > prevent a duplicate namespace from being written in a different > > codebehind
> > > > page? Is there a better place to write all the project namespaces for
> > > more
> > > > centralized accessibility?
> > > >
> > > > And finally, how do namespaces DIFFER from classes?
> > > >
> > > > Random
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #16
Hi Random,
I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?
A .Net assembly is a compiled DLL. The data in the code files is compiled
into binary code in the DLL, including all the namespace information,
references, etc. Once compiled into a DLL, your CodeBehind class files are
nothing but dead weight. They are not used; the DLL is. So, forget about the
"written classes". Think about the classes themselves, rather than the code
you write to create them.
As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
You wouldn't be able to compile OR use it. An aspx Page is a composite of 2
distinct entities: the Page Template (.aspx) and the CodeBehind class. The
Page Template inherits the CodeBehind class, which inherits
System.Web.UI.Page. The .aspx file by itself can do nothing without
CodeBehind, whether that is in the same (.aspx) file as the Page Template, a
CodeBehind file, or a DLL. The important thing is that the .aspx Page
Template has a reference in it telling it where to look for the class
definition that it inherits. If the CodeBehind is compiled into a DLL, and
that DLL is in one of the locations that ASP.Net can find it (Global
Assembly Cache or \bin folder), ASP.Net uses Reflection to query the
assembly for the class, based upon the NameSpace and Class name of the
class. All of this information is contained in the DLL itself.
Since the class is found in the assembly, how would the aspx page know where to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't it make more sense to put all the code into a *.vb or *.cs file where it can be centrally referenced?
Again, only the CodeBehind is compiled. The Page Template (.aspx) must have
a Reference in it telling it where to find the CodeBehind class. There IS
not "central source" for information about .Net classes. That is why you can
simply put your DLLs into the \bin folder of your web app, and they will be
found. Once found, the .Net platform can query the DLLs to find the DLL
needed, and the class inside the DLL to use.

Take a look at the following example, from an ASPX page I created:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="WebForm1.aspx.vb" Inherits="ControlTest.WebForm1"%>

The "CodeBehind" attribute is there solely for the benefit of Visual
Studio.Net. It tells VS.Net what file to compile to create the DLL used by
the Page class(es). The "Inherits" directive is the key. Note that it
contains no information about the location of the DLL. ASP.Net KNOWS where
the DLL can be located. Instead, it contains a reference to a NameSpace and
a class, which it can find by using Reflection on the assemblies in the \bin
folder and the GAC.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#D**************@TK2MSFTNGP10.phx.gbl... I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am trying to clarify here. I thought that by asking 'basic' questions, I might get a better understanding of how things fit into the whole. So please be patient with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't
understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know where to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case, wouldn't it make more sense to put all the code into a *.vb or *.cs file where it can be centrally referenced?

You are right, I think there is something very simple I am misunderstanding, but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being written
in central locations.

You can have any number of pages inherit from the same class - as long as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so

it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
Okay, that clarifies the "Inherits" vs. "Imports" question very well.
Thanks.

As far as the namespace being available in the assembly, though, let me
give
you an example...

Using the portal code I gave before, would I be able to write another aspx page, use the same "Inherits=<fully qualified class name>" phrasing,

without
that class being written into the different codebehind page referenced in the new aspx page?

If yes, why? Shouldn't namespaces be written in a more centrally

referenced
file?

If no, then how can the assembly keep track of all the declared

namespaces?
And what would it do if two or more codebehind references had the same
namespace and class written in them?

Random

"Marina" <so*****@nospam.com> wrote in message
news:eq**************@TK2MSFTNGP10.phx.gbl...
> This inherits attribute, refers to the name of the class this page
inherits
> from. The class's name is CDefault, but it is located in the
> ASPNET.StarterKit.Portal namespace, and so the namespace has to preceed it.
>
> At runtime, asp.net looks for a class with the name in the inherits
> attribute.
>
> This has nothing to do with projects, or namespaces being available. It
is
> just the fully qualified name of the class.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:OI*************@TK2MSFTNGP09.phx.gbl...
> > Hmm. I'm trying to teach myself from examples and tutorials and

books.
> > Specifically in this case, I'm trying to learn from the MS
> PortalStarterKit.
> > Specifically, the default page in that example has as the first

line in
> > default.aspx:
> >
> > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> AutoEventWireup="false"
> > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> >
> > The codebehind page has:
> >
> > Namespace ASPNET.StarterKit.Portal
> > Public Class CDefault
> > Inherits System.Web.UI.Page
> > Private Sub Page_Load(ByVal sender As System.Object, ByVal
e As
> > System.EventArgs) Handles MyBase.Load
> > <code here>
> > End Sub
> > End Class
> > End Namespace
> >
> > I'm trying to find out how and why this works the way that it
does. It's
> > more complex than the examples given by tutorials and books.
> >
> > And again, I'm trying to figure out how the namespace declared here makes
> > it's way into the assembly. And because it does, somehow, does that make
> it
> > available through the entire project?
> >
> > Random
> >
> > "Marina" <so*****@nospam.com> wrote in message
> > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > First of all, namespaces can be used with the 'Imports' keyword,

so
as
> not
> > > have to write out the full namespace for every class, not the
'Inherits'
> > > attribute.
> > >
> > > Think of namespaces as folders in your file system, and classes as the
> > files
> > > in them. So a namespace itself isn't anything but an

organizational > > > container for classes - just as a folder is just a container for
files.
> > > Classes are the actual things that you instantiate, and call methods on.
> > >
> > > I didn't really understand your questions. I think they all stem

from
> not
> > > understanding what a namespace actually is.
> > >
> > > "Random" <ci*******@hotmail.com> wrote in message
> > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > I'm confused about the proper use and usefulness of
namespaces. I > > beleive
> > > I
> > > > understand the purpose is so the developer can put classes within > > > namespaces
> > > > to essentially organize your code. And I understand that you
declare
> > your
> > > > intention to use a namespace within a page through the "Inherits" > > > attribute.
> > > > I know that using "Inherits" isn't absolutely necessary, it's just > > > > recommended so the developer doesn't have to type out the
entire > > namespace
> > > > in code. I know that namespaces have to appear in the project
> assembly,
> > > > however...
> > > >
> > > > How does the assembly find a namespace that the developer has
> > written????
> > > > In all the examples I've seen, namespaces have been written in
> > codebehind
> > > > pages. How does this make them accessible to the entire

project? > > What's
> > > to
> > > > prevent a duplicate namespace from being written in a different > > codebehind
> > > > page? Is there a better place to write all the project namespaces for
> > > more
> > > > centralized accessibility?
> > > >
> > > > And finally, how do namespaces DIFFER from classes?
> > > >
> > > > Random
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #17
On this, I'm really just questioning the way the StarterPortal is built. I
understand and appreciate how ASP.NET is built to seperate the code from the
presentation layer. I did much the same by using include files containing
commonly used functions in classic ASP. My point is, in order to reuse any
namespaces/classes/functions between pages, wouldn't it be better to put
them in one, or a small group of files that are referenced seperately from
the codebehind page? It would seem just much easier to keep track of them
that way, to make it simpler to reference them during development, instead
of making it appear as though a class and set of functions are solely for
use with one aspx page.
"Marina" <so*****@nospam.com> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl...
My point was about the understandings of .NET, not your experience with
anything else. I think if the distinction between what a namespace is, and
what a class is, is unclear, then you can't really go anywhere until it is.
When VS.NEt compiles your web project, it places all the classes in one DLL. When a page is requested, the class in this Inherits attribute is looked for in the bin directory - so it has to be compiled into one of the DLL's that
is located in that directory. This is done by the asp.net process at run
time - nothing to do with visual studio. Visual studio doesn't keep track
of anything - it just compiles all the classes in the project into one
assembly. If there are duplicate class names, then the compilation process
will fail.

I am still not understanding what you think is being kept track of and
where. Or what you ask when you talk about keeping the code in .vb and ..cs files - the source is already in those files. What does "what if I wrote an aspx page that inherited a class contained in a codebehind page that was NOT referenced by the aspx page?" mean? How can you write a page that inherits
from a codebehind class - but yet not reference it?

Do you have a book that you are reading about this from, that is not
explaining it well?
"Random" <ci*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am
disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am

trying
to clarify here. I thought that by asking 'basic' questions, I might get a
better understanding of how things fit into the whole. So please be patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not

necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it

can
be centrally referenced?

You are right, I think there is something very simple I am

misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being

written
in central locations.

You can have any number of pages inherit from the same class - as long

as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
> Okay, that clarifies the "Inherits" vs. "Imports" question very
well. > Thanks.
>
> As far as the namespace being available in the assembly, though, let me give
> you an example...
>
> Using the portal code I gave before, would I be able to write another aspx
> page, use the same "Inherits=<fully qualified class name>" phrasing,
without
> that class being written into the different codebehind page
referenced
in
> the new aspx page?
>
> If yes, why? Shouldn't namespaces be written in a more centrally
referenced
> file?
>
> If no, then how can the assembly keep track of all the declared
namespaces?
> And what would it do if two or more codebehind references had the
same > namespace and class written in them?
>
> Random
>
> "Marina" <so*****@nospam.com> wrote in message
> news:eq**************@TK2MSFTNGP10.phx.gbl...
> > This inherits attribute, refers to the name of the class this page
> inherits
> > from. The class's name is CDefault, but it is located in the
> > ASPNET.StarterKit.Portal namespace, and so the namespace has to

preceed
> it.
> >
> > At runtime, asp.net looks for a class with the name in the inherits > > attribute.
> >
> > This has nothing to do with projects, or namespaces being available. It
is
> > just the fully qualified name of the class.
> >
> > "Random" <ci*******@hotmail.com> wrote in message
> > news:OI*************@TK2MSFTNGP09.phx.gbl...
> > > Hmm. I'm trying to teach myself from examples and tutorials and
books.
> > > Specifically in this case, I'm trying to learn from the MS
> > PortalStarterKit.
> > > Specifically, the default page in that example has as the first line in
> > > default.aspx:
> > >
> > > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> > AutoEventWireup="false"
> > > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> > >
> > > The codebehind page has:
> > >
> > > Namespace ASPNET.StarterKit.Portal
> > > Public Class CDefault
> > > Inherits System.Web.UI.Page
> > > Private Sub Page_Load(ByVal sender As System.Object,
ByVal e As
> > > System.EventArgs) Handles MyBase.Load
> > > <code here>
> > > End Sub
> > > End Class
> > > End Namespace
> > >
> > > I'm trying to find out how and why this works the way that it does. > It's
> > > more complex than the examples given by tutorials and books.
> > >
> > > And again, I'm trying to figure out how the namespace declared here > makes
> > > it's way into the assembly. And because it does, somehow, does that > make
> > it
> > > available through the entire project?
> > >
> > > Random
> > >
> > > "Marina" <so*****@nospam.com> wrote in message
> > > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > > First of all, namespaces can be used with the 'Imports'
keyword, so
as
> > not
> > > > have to write out the full namespace for every class, not the
> 'Inherits'
> > > > attribute.
> > > >
> > > > Think of namespaces as folders in your file system, and
classes
as the
> > > files
> > > > in them. So a namespace itself isn't anything but an

organizational
> > > > container for classes - just as a folder is just a container
for > files.
> > > > Classes are the actual things that you instantiate, and call

methods
> on.
> > > >
> > > > I didn't really understand your questions. I think they all stem from
> > not
> > > > understanding what a namespace actually is.
> > > >
> > > > "Random" <ci*******@hotmail.com> wrote in message
> > > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > > I'm confused about the proper use and usefulness of

namespaces.
I
> > > beleive
> > > > I
> > > > > understand the purpose is so the developer can put classes

within
> > > > namespaces
> > > > > to essentially organize your code. And I understand that you > declare
> > > your
> > > > > intention to use a namespace within a page through the

"Inherits"
> > > > attribute.
> > > > > I know that using "Inherits" isn't absolutely necessary, it's just
> > > > > recommended so the developer doesn't have to type out the

entire > > > namespace
> > > > > in code. I know that namespaces have to appear in the
project > > assembly,
> > > > > however...
> > > > >
> > > > > How does the assembly find a namespace that the developer has > > > written????
> > > > > In all the examples I've seen, namespaces have been written in > > > codebehind
> > > > > pages. How does this make them accessible to the entire

project?
> > > What's
> > > > to
> > > > > prevent a duplicate namespace from being written in a

different > > > codebehind
> > > > > page? Is there a better place to write all the project

namespaces
> for
> > > > more
> > > > > centralized accessibility?
> > > > >
> > > > > And finally, how do namespaces DIFFER from classes?
> > > > >
> > > > > Random
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #18
On this, I'm really just questioning the way the StarterPortal is built. I
understand and appreciate how ASP.NET is built to seperate the code from the
presentation layer. I did much the same by using include files containing
commonly used functions in classic ASP. My point is, in order to reuse any
namespaces/classes/functions between pages, wouldn't it be better to put
them in one, or a small group of files that are referenced seperately from
the codebehind page? It would seem just much easier to keep track of them
that way, to make it simpler to reference them during development, instead
of making it appear as though a class and set of functions are solely for
use with one aspx page.
"Marina" <so*****@nospam.com> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl...
My point was about the understandings of .NET, not your experience with
anything else. I think if the distinction between what a namespace is, and
what a class is, is unclear, then you can't really go anywhere until it is.
When VS.NEt compiles your web project, it places all the classes in one DLL. When a page is requested, the class in this Inherits attribute is looked for in the bin directory - so it has to be compiled into one of the DLL's that
is located in that directory. This is done by the asp.net process at run
time - nothing to do with visual studio. Visual studio doesn't keep track
of anything - it just compiles all the classes in the project into one
assembly. If there are duplicate class names, then the compilation process
will fail.

I am still not understanding what you think is being kept track of and
where. Or what you ask when you talk about keeping the code in .vb and ..cs files - the source is already in those files. What does "what if I wrote an aspx page that inherited a class contained in a codebehind page that was NOT referenced by the aspx page?" mean? How can you write a page that inherits
from a codebehind class - but yet not reference it?

Do you have a book that you are reading about this from, that is not
explaining it well?
"Random" <ci*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am
disappointed that a lot of the 'beginner' material has been unhelpful when
it comes to an architectural overview of ASP.NET, which is what I am

trying
to clarify here. I thought that by asking 'basic' questions, I might get a
better understanding of how things fit into the whole. So please be patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not

necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it

can
be centrally referenced?

You are right, I think there is something very simple I am

misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being

written
in central locations.

You can have any number of pages inherit from the same class - as long

as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
> Okay, that clarifies the "Inherits" vs. "Imports" question very
well. > Thanks.
>
> As far as the namespace being available in the assembly, though, let me give
> you an example...
>
> Using the portal code I gave before, would I be able to write another aspx
> page, use the same "Inherits=<fully qualified class name>" phrasing,
without
> that class being written into the different codebehind page
referenced
in
> the new aspx page?
>
> If yes, why? Shouldn't namespaces be written in a more centrally
referenced
> file?
>
> If no, then how can the assembly keep track of all the declared
namespaces?
> And what would it do if two or more codebehind references had the
same > namespace and class written in them?
>
> Random
>
> "Marina" <so*****@nospam.com> wrote in message
> news:eq**************@TK2MSFTNGP10.phx.gbl...
> > This inherits attribute, refers to the name of the class this page
> inherits
> > from. The class's name is CDefault, but it is located in the
> > ASPNET.StarterKit.Portal namespace, and so the namespace has to

preceed
> it.
> >
> > At runtime, asp.net looks for a class with the name in the inherits > > attribute.
> >
> > This has nothing to do with projects, or namespaces being available. It
is
> > just the fully qualified name of the class.
> >
> > "Random" <ci*******@hotmail.com> wrote in message
> > news:OI*************@TK2MSFTNGP09.phx.gbl...
> > > Hmm. I'm trying to teach myself from examples and tutorials and
books.
> > > Specifically in this case, I'm trying to learn from the MS
> > PortalStarterKit.
> > > Specifically, the default page in that example has as the first line in
> > > default.aspx:
> > >
> > > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> > AutoEventWireup="false"
> > > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> > >
> > > The codebehind page has:
> > >
> > > Namespace ASPNET.StarterKit.Portal
> > > Public Class CDefault
> > > Inherits System.Web.UI.Page
> > > Private Sub Page_Load(ByVal sender As System.Object,
ByVal e As
> > > System.EventArgs) Handles MyBase.Load
> > > <code here>
> > > End Sub
> > > End Class
> > > End Namespace
> > >
> > > I'm trying to find out how and why this works the way that it does. > It's
> > > more complex than the examples given by tutorials and books.
> > >
> > > And again, I'm trying to figure out how the namespace declared here > makes
> > > it's way into the assembly. And because it does, somehow, does that > make
> > it
> > > available through the entire project?
> > >
> > > Random
> > >
> > > "Marina" <so*****@nospam.com> wrote in message
> > > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > > First of all, namespaces can be used with the 'Imports'
keyword, so
as
> > not
> > > > have to write out the full namespace for every class, not the
> 'Inherits'
> > > > attribute.
> > > >
> > > > Think of namespaces as folders in your file system, and
classes
as the
> > > files
> > > > in them. So a namespace itself isn't anything but an

organizational
> > > > container for classes - just as a folder is just a container
for > files.
> > > > Classes are the actual things that you instantiate, and call

methods
> on.
> > > >
> > > > I didn't really understand your questions. I think they all stem from
> > not
> > > > understanding what a namespace actually is.
> > > >
> > > > "Random" <ci*******@hotmail.com> wrote in message
> > > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > > I'm confused about the proper use and usefulness of

namespaces.
I
> > > beleive
> > > > I
> > > > > understand the purpose is so the developer can put classes

within
> > > > namespaces
> > > > > to essentially organize your code. And I understand that you > declare
> > > your
> > > > > intention to use a namespace within a page through the

"Inherits"
> > > > attribute.
> > > > > I know that using "Inherits" isn't absolutely necessary, it's just
> > > > > recommended so the developer doesn't have to type out the

entire > > > namespace
> > > > > in code. I know that namespaces have to appear in the
project > > assembly,
> > > > > however...
> > > > >
> > > > > How does the assembly find a namespace that the developer has > > > written????
> > > > > In all the examples I've seen, namespaces have been written in > > > codebehind
> > > > > pages. How does this make them accessible to the entire

project?
> > > What's
> > > > to
> > > > > prevent a duplicate namespace from being written in a

different > > > codebehind
> > > > > page? Is there a better place to write all the project

namespaces
> for
> > > > more
> > > > > centralized accessibility?
> > > > >
> > > > > And finally, how do namespaces DIFFER from classes?
> > > > >
> > > > > Random
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #19
hoo, boy. What a thread this is turning out to be. First, I do understand,
and you have confirmed a lot of things I have suspected.

Let me take a different approach on this, if I may. Let's say I have two
aspx pages that I know I want utilize a specific function within, that is
contained in a class. Without having to copy/paste this function into a
different class in a different codebehind page (because I don't want them to
have the same codebehind page), how can I reference this function.

NONE of the tutorials or materials I have read go beyond a one page example.
Seperation of code and HTML... fine. It's the sharing of code through
namespaces and classes that I'm having difficulty grasping at this point.

"Kevin Spencer" <uc*@ftc.gov> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Hi Random,
I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all
these written classes are?
A .Net assembly is a compiled DLL. The data in the code files is compiled
into binary code in the DLL, including all the namespace information,
references, etc. Once compiled into a DLL, your CodeBehind class files are
nothing but dead weight. They are not used; the DLL is. So, forget about

the "written classes". Think about the classes themselves, rather than the code you write to create them.
As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
You wouldn't be able to compile OR use it. An aspx Page is a composite of

2 distinct entities: the Page Template (.aspx) and the CodeBehind class. The
Page Template inherits the CodeBehind class, which inherits
System.Web.UI.Page. The .aspx file by itself can do nothing without
CodeBehind, whether that is in the same (.aspx) file as the Page Template, a CodeBehind file, or a DLL. The important thing is that the .aspx Page
Template has a reference in it telling it where to look for the class
definition that it inherits. If the CodeBehind is compiled into a DLL, and
that DLL is in one of the locations that ASP.Net can find it (Global
Assembly Cache or \bin folder), ASP.Net uses Reflection to query the
assembly for the class, based upon the NameSpace and Class name of the
class. All of this information is contained in the DLL itself.
Since the class is found in the assembly, how would the aspx page know where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it

can
be centrally referenced?


Again, only the CodeBehind is compiled. The Page Template (.aspx) must

have a Reference in it telling it where to find the CodeBehind class. There IS
not "central source" for information about .Net classes. That is why you can simply put your DLLs into the \bin folder of your web app, and they will be found. Once found, the .Net platform can query the DLLs to find the DLL
needed, and the class inside the DLL to use.

Take a look at the following example, from an ASPX page I created:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="WebForm1.aspx.vb" Inherits="ControlTest.WebForm1"%>

The "CodeBehind" attribute is there solely for the benefit of Visual
Studio.Net. It tells VS.Net what file to compile to create the DLL used by
the Page class(es). The "Inherits" directive is the key. Note that it
contains no information about the location of the DLL. ASP.Net KNOWS where
the DLL can be located. Instead, it contains a reference to a NameSpace and a class, which it can find by using Reflection on the assemblies in the \bin folder and the GAC.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#D**************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am
disappointed that a lot of the 'beginner' material has been unhelpful when it comes to an architectural overview of ASP.NET, which is what I am

trying
to clarify here. I thought that by asking 'basic' questions, I might get a
better understanding of how things fit into the whole. So please be patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not

necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it

can
be centrally referenced?

You are right, I think there is something very simple I am

misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being

written
in central locations.

You can have any number of pages inherit from the same class - as long

as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
> Okay, that clarifies the "Inherits" vs. "Imports" question very
well. > Thanks.
>
> As far as the namespace being available in the assembly, though, let me give
> you an example...
>
> Using the portal code I gave before, would I be able to write another aspx
> page, use the same "Inherits=<fully qualified class name>" phrasing,
without
> that class being written into the different codebehind page
referenced
in
> the new aspx page?
>
> If yes, why? Shouldn't namespaces be written in a more centrally
referenced
> file?
>
> If no, then how can the assembly keep track of all the declared
namespaces?
> And what would it do if two or more codebehind references had the
same > namespace and class written in them?
>
> Random
>
> "Marina" <so*****@nospam.com> wrote in message
> news:eq**************@TK2MSFTNGP10.phx.gbl...
> > This inherits attribute, refers to the name of the class this page
> inherits
> > from. The class's name is CDefault, but it is located in the
> > ASPNET.StarterKit.Portal namespace, and so the namespace has to

preceed
> it.
> >
> > At runtime, asp.net looks for a class with the name in the inherits > > attribute.
> >
> > This has nothing to do with projects, or namespaces being available. It
is
> > just the fully qualified name of the class.
> >
> > "Random" <ci*******@hotmail.com> wrote in message
> > news:OI*************@TK2MSFTNGP09.phx.gbl...
> > > Hmm. I'm trying to teach myself from examples and tutorials and
books.
> > > Specifically in this case, I'm trying to learn from the MS
> > PortalStarterKit.
> > > Specifically, the default page in that example has as the first line in
> > > default.aspx:
> > >
> > > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> > AutoEventWireup="false"
> > > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> > >
> > > The codebehind page has:
> > >
> > > Namespace ASPNET.StarterKit.Portal
> > > Public Class CDefault
> > > Inherits System.Web.UI.Page
> > > Private Sub Page_Load(ByVal sender As System.Object,
ByVal e As
> > > System.EventArgs) Handles MyBase.Load
> > > <code here>
> > > End Sub
> > > End Class
> > > End Namespace
> > >
> > > I'm trying to find out how and why this works the way that it does. > It's
> > > more complex than the examples given by tutorials and books.
> > >
> > > And again, I'm trying to figure out how the namespace declared here > makes
> > > it's way into the assembly. And because it does, somehow, does that > make
> > it
> > > available through the entire project?
> > >
> > > Random
> > >
> > > "Marina" <so*****@nospam.com> wrote in message
> > > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > > First of all, namespaces can be used with the 'Imports'
keyword, so
as
> > not
> > > > have to write out the full namespace for every class, not the
> 'Inherits'
> > > > attribute.
> > > >
> > > > Think of namespaces as folders in your file system, and
classes
as the
> > > files
> > > > in them. So a namespace itself isn't anything but an

organizational
> > > > container for classes - just as a folder is just a container
for > files.
> > > > Classes are the actual things that you instantiate, and call

methods
> on.
> > > >
> > > > I didn't really understand your questions. I think they all stem from
> > not
> > > > understanding what a namespace actually is.
> > > >
> > > > "Random" <ci*******@hotmail.com> wrote in message
> > > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > > I'm confused about the proper use and usefulness of

namespaces.
I
> > > beleive
> > > > I
> > > > > understand the purpose is so the developer can put classes

within
> > > > namespaces
> > > > > to essentially organize your code. And I understand that you > declare
> > > your
> > > > > intention to use a namespace within a page through the

"Inherits"
> > > > attribute.
> > > > > I know that using "Inherits" isn't absolutely necessary, it's just
> > > > > recommended so the developer doesn't have to type out the

entire > > > namespace
> > > > > in code. I know that namespaces have to appear in the
project > > assembly,
> > > > > however...
> > > > >
> > > > > How does the assembly find a namespace that the developer has > > > written????
> > > > > In all the examples I've seen, namespaces have been written in > > > codebehind
> > > > > pages. How does this make them accessible to the entire

project?
> > > What's
> > > > to
> > > > > prevent a duplicate namespace from being written in a

different > > > codebehind
> > > > > page? Is there a better place to write all the project

namespaces
> for
> > > > more
> > > > > centralized accessibility?
> > > > >
> > > > > And finally, how do namespaces DIFFER from classes?
> > > > >
> > > > > Random
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #20
hoo, boy. What a thread this is turning out to be. First, I do understand,
and you have confirmed a lot of things I have suspected.

Let me take a different approach on this, if I may. Let's say I have two
aspx pages that I know I want utilize a specific function within, that is
contained in a class. Without having to copy/paste this function into a
different class in a different codebehind page (because I don't want them to
have the same codebehind page), how can I reference this function.

NONE of the tutorials or materials I have read go beyond a one page example.
Seperation of code and HTML... fine. It's the sharing of code through
namespaces and classes that I'm having difficulty grasping at this point.

"Kevin Spencer" <uc*@ftc.gov> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Hi Random,
I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily
need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all
these written classes are?
A .Net assembly is a compiled DLL. The data in the code files is compiled
into binary code in the DLL, including all the namespace information,
references, etc. Once compiled into a DLL, your CodeBehind class files are
nothing but dead weight. They are not used; the DLL is. So, forget about

the "written classes". Think about the classes themselves, rather than the code you write to create them.
As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
You wouldn't be able to compile OR use it. An aspx Page is a composite of

2 distinct entities: the Page Template (.aspx) and the CodeBehind class. The
Page Template inherits the CodeBehind class, which inherits
System.Web.UI.Page. The .aspx file by itself can do nothing without
CodeBehind, whether that is in the same (.aspx) file as the Page Template, a CodeBehind file, or a DLL. The important thing is that the .aspx Page
Template has a reference in it telling it where to look for the class
definition that it inherits. If the CodeBehind is compiled into a DLL, and
that DLL is in one of the locations that ASP.Net can find it (Global
Assembly Cache or \bin folder), ASP.Net uses Reflection to query the
assembly for the class, based upon the NameSpace and Class name of the
class. All of this information is contained in the DLL itself.
Since the class is found in the assembly, how would the aspx page know where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it

can
be centrally referenced?


Again, only the CodeBehind is compiled. The Page Template (.aspx) must

have a Reference in it telling it where to find the CodeBehind class. There IS
not "central source" for information about .Net classes. That is why you can simply put your DLLs into the \bin folder of your web app, and they will be found. Once found, the .Net platform can query the DLLs to find the DLL
needed, and the class inside the DLL to use.

Take a look at the following example, from an ASPX page I created:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="WebForm1.aspx.vb" Inherits="ControlTest.WebForm1"%>

The "CodeBehind" attribute is there solely for the benefit of Visual
Studio.Net. It tells VS.Net what file to compile to create the DLL used by
the Page class(es). The "Inherits" directive is the key. Note that it
contains no information about the location of the DLL. ASP.Net KNOWS where
the DLL can be located. Instead, it contains a reference to a NameSpace and a class, which it can find by using Reflection on the assemblies in the \bin folder and the GAC.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#D**************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics. I am
disappointed that a lot of the 'beginner' material has been unhelpful when it comes to an architectural overview of ASP.NET, which is what I am

trying
to clarify here. I thought that by asking 'basic' questions, I might get a
better understanding of how things fit into the whole. So please be patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not

necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all
these written classes are?

As another example, what if I wrote an aspx page that inherited a class
contained in a codebehind page that was NOT referenced by the aspx page?
Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it

can
be centrally referenced?

You are right, I think there is something very simple I am

misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
I have no idea what you are talking about to be honest.

The class is already in a namespace - the Inherits attribute is just
referencing. It isn't creating a new namespace or a new class. So I have
no
idea what you are talking about when you ask about namespaces being

written
in central locations.

You can have any number of pages inherit from the same class - as long

as that class actually exists. In the visual studio model, you would have to manually do that, because it assume a 1 to 1 ration between pages and code behind classes.

If you tried to compiled two classes with the same name into the same
assembly, the compiler would not allow you to do this. The assembly

itself
knows what classes it has, and what namespace each one is in, in it's
manifest.

I would recommend you start at the very basics of ASP.NET, it sounds like you are missing some basic concept about how this all works. In your

first
post you asked about the difference between a namespace and a class - so it
seems like you need to go to the beginning of .NET, and not just into the middle of ASP.NET.

"Random" <ci*******@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...
> Okay, that clarifies the "Inherits" vs. "Imports" question very
well. > Thanks.
>
> As far as the namespace being available in the assembly, though, let me give
> you an example...
>
> Using the portal code I gave before, would I be able to write another aspx
> page, use the same "Inherits=<fully qualified class name>" phrasing,
without
> that class being written into the different codebehind page
referenced
in
> the new aspx page?
>
> If yes, why? Shouldn't namespaces be written in a more centrally
referenced
> file?
>
> If no, then how can the assembly keep track of all the declared
namespaces?
> And what would it do if two or more codebehind references had the
same > namespace and class written in them?
>
> Random
>
> "Marina" <so*****@nospam.com> wrote in message
> news:eq**************@TK2MSFTNGP10.phx.gbl...
> > This inherits attribute, refers to the name of the class this page
> inherits
> > from. The class's name is CDefault, but it is located in the
> > ASPNET.StarterKit.Portal namespace, and so the namespace has to

preceed
> it.
> >
> > At runtime, asp.net looks for a class with the name in the inherits > > attribute.
> >
> > This has nothing to do with projects, or namespaces being available. It
is
> > just the fully qualified name of the class.
> >
> > "Random" <ci*******@hotmail.com> wrote in message
> > news:OI*************@TK2MSFTNGP09.phx.gbl...
> > > Hmm. I'm trying to teach myself from examples and tutorials and
books.
> > > Specifically in this case, I'm trying to learn from the MS
> > PortalStarterKit.
> > > Specifically, the default page in that example has as the first line in
> > > default.aspx:
> > >
> > > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> > AutoEventWireup="false"
> > > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> > >
> > > The codebehind page has:
> > >
> > > Namespace ASPNET.StarterKit.Portal
> > > Public Class CDefault
> > > Inherits System.Web.UI.Page
> > > Private Sub Page_Load(ByVal sender As System.Object,
ByVal e As
> > > System.EventArgs) Handles MyBase.Load
> > > <code here>
> > > End Sub
> > > End Class
> > > End Namespace
> > >
> > > I'm trying to find out how and why this works the way that it does. > It's
> > > more complex than the examples given by tutorials and books.
> > >
> > > And again, I'm trying to figure out how the namespace declared here > makes
> > > it's way into the assembly. And because it does, somehow, does that > make
> > it
> > > available through the entire project?
> > >
> > > Random
> > >
> > > "Marina" <so*****@nospam.com> wrote in message
> > > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > > First of all, namespaces can be used with the 'Imports'
keyword, so
as
> > not
> > > > have to write out the full namespace for every class, not the
> 'Inherits'
> > > > attribute.
> > > >
> > > > Think of namespaces as folders in your file system, and
classes
as the
> > > files
> > > > in them. So a namespace itself isn't anything but an

organizational
> > > > container for classes - just as a folder is just a container
for > files.
> > > > Classes are the actual things that you instantiate, and call

methods
> on.
> > > >
> > > > I didn't really understand your questions. I think they all stem from
> > not
> > > > understanding what a namespace actually is.
> > > >
> > > > "Random" <ci*******@hotmail.com> wrote in message
> > > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > > I'm confused about the proper use and usefulness of

namespaces.
I
> > > beleive
> > > > I
> > > > > understand the purpose is so the developer can put classes

within
> > > > namespaces
> > > > > to essentially organize your code. And I understand that you > declare
> > > your
> > > > > intention to use a namespace within a page through the

"Inherits"
> > > > attribute.
> > > > > I know that using "Inherits" isn't absolutely necessary, it's just
> > > > > recommended so the developer doesn't have to type out the

entire > > > namespace
> > > > > in code. I know that namespaces have to appear in the
project > > assembly,
> > > > > however...
> > > > >
> > > > > How does the assembly find a namespace that the developer has > > > written????
> > > > > In all the examples I've seen, namespaces have been written in > > > codebehind
> > > > > pages. How does this make them accessible to the entire

project?
> > > What's
> > > > to
> > > > > prevent a duplicate namespace from being written in a

different > > > codebehind
> > > > > page? Is there a better place to write all the project

namespaces
> for
> > > > more
> > > > > centralized accessibility?
> > > > >
> > > > > And finally, how do namespaces DIFFER from classes?
> > > > >
> > > > > Random
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #21
You simply create a Class Library with the function(s) you want in it.
Reference the Class Library in your Page, and use it.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#k**************@TK2MSFTNGP12.phx.gbl...
hoo, boy. What a thread this is turning out to be. First, I do understand, and you have confirmed a lot of things I have suspected.

Let me take a different approach on this, if I may. Let's say I have two
aspx pages that I know I want utilize a specific function within, that is
contained in a class. Without having to copy/paste this function into a
different class in a different codebehind page (because I don't want them to have the same codebehind page), how can I reference this function.

NONE of the tutorials or materials I have read go beyond a one page example. Seperation of code and HTML... fine. It's the sharing of code through
namespaces and classes that I'm having difficulty grasping at this point.

"Kevin Spencer" <uc*@ftc.gov> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Hi Random,
I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all these written classes are?
A .Net assembly is a compiled DLL. The data in the code files is compiled
into binary code in the DLL, including all the namespace information,
references, etc. Once compiled into a DLL, your CodeBehind class files are nothing but dead weight. They are not used; the DLL is. So, forget about

the
"written classes". Think about the classes themselves, rather than the

code
you write to create them.
As another example, what if I wrote an aspx page that inherited a class contained in a codebehind page that was NOT referenced by the aspx page?

You wouldn't be able to compile OR use it. An aspx Page is a composite of 2
distinct entities: the Page Template (.aspx) and the CodeBehind class.
The Page Template inherits the CodeBehind class, which inherits
System.Web.UI.Page. The .aspx file by itself can do nothing without
CodeBehind, whether that is in the same (.aspx) file as the Page Template, a
CodeBehind file, or a DLL. The important thing is that the .aspx Page
Template has a reference in it telling it where to look for the class
definition that it inherits. If the CodeBehind is compiled into a DLL,
and that DLL is in one of the locations that ASP.Net can find it (Global
Assembly Cache or \bin folder), ASP.Net uses Reflection to query the
assembly for the class, based upon the NameSpace and Class name of the
class. All of this information is contained in the DLL itself.
Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where
it can
be centrally referenced?


Again, only the CodeBehind is compiled. The Page Template (.aspx) must

have
a Reference in it telling it where to find the CodeBehind class. There IS not "central source" for information about .Net classes. That is why you

can
simply put your DLLs into the \bin folder of your web app, and they will

be
found. Once found, the .Net platform can query the DLLs to find the DLL
needed, and the class inside the DLL to use.

Take a look at the following example, from an ASPX page I created:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="WebForm1.aspx.vb" Inherits="ControlTest.WebForm1"%>

The "CodeBehind" attribute is there solely for the benefit of Visual
Studio.Net. It tells VS.Net what file to compile to create the DLL used by the Page class(es). The "Inherits" directive is the key. Note that it
contains no information about the location of the DLL. ASP.Net KNOWS where the DLL can be located. Instead, it contains a reference to a NameSpace

and
a class, which it can find by using Reflection on the assemblies in the

\bin
folder and the GAC.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#D**************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics.
I am
disappointed that a lot of the 'beginner' material has been unhelpful when it comes to an architectural overview of ASP.NET, which is what I am

trying
to clarify here. I thought that by asking 'basic' questions, I might get
a
better understanding of how things fit into the whole. So please be

patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not

necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where
all these written classes are?

As another example, what if I wrote an aspx page that inherited a class contained in a codebehind page that was NOT referenced by the aspx page? Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it can
be centrally referenced?

You are right, I think there is something very simple I am

misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
> I have no idea what you are talking about to be honest.
>
> The class is already in a namespace - the Inherits attribute is just
> referencing. It isn't creating a new namespace or a new class. So I

have
no
> idea what you are talking about when you ask about namespaces being
written
> in central locations.
>
> You can have any number of pages inherit from the same class - as
long as
> that class actually exists. In the visual studio model, you would
have to
> manually do that, because it assume a 1 to 1 ration between pages
and code
> behind classes.
>
> If you tried to compiled two classes with the same name into the
same > assembly, the compiler would not allow you to do this. The assembly
itself
> knows what classes it has, and what namespace each one is in, in it's > manifest.
>
> I would recommend you start at the very basics of ASP.NET, it sounds

like
> you are missing some basic concept about how this all works. In your first
> post you asked about the difference between a namespace and a class - so it
> seems like you need to go to the beginning of .NET, and not just
into the
> middle of ASP.NET.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:ua**************@TK2MSFTNGP09.phx.gbl...
> > Okay, that clarifies the "Inherits" vs. "Imports" question very well. > > Thanks.
> >
> > As far as the namespace being available in the assembly, though,
let me
> give
> > you an example...
> >
> > Using the portal code I gave before, would I be able to write another aspx
> > page, use the same "Inherits=<fully qualified class name>"
phrasing, > without
> > that class being written into the different codebehind page
referenced in
> > the new aspx page?
> >
> > If yes, why? Shouldn't namespaces be written in a more centrally
> referenced
> > file?
> >
> > If no, then how can the assembly keep track of all the declared
> namespaces?
> > And what would it do if two or more codebehind references had the same > > namespace and class written in them?
> >
> > Random
> >
> > "Marina" <so*****@nospam.com> wrote in message
> > news:eq**************@TK2MSFTNGP10.phx.gbl...
> > > This inherits attribute, refers to the name of the class this page > > inherits
> > > from. The class's name is CDefault, but it is located in the
> > > ASPNET.StarterKit.Portal namespace, and so the namespace has to
preceed
> > it.
> > >
> > > At runtime, asp.net looks for a class with the name in the inherits > > > attribute.
> > >
> > > This has nothing to do with projects, or namespaces being available. It
> is
> > > just the fully qualified name of the class.
> > >
> > > "Random" <ci*******@hotmail.com> wrote in message
> > > news:OI*************@TK2MSFTNGP09.phx.gbl...
> > > > Hmm. I'm trying to teach myself from examples and tutorials and > books.
> > > > Specifically in this case, I'm trying to learn from the MS
> > > PortalStarterKit.
> > > > Specifically, the default page in that example has as the first line
> in
> > > > default.aspx:
> > > >
> > > > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> > > AutoEventWireup="false"
> > > > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> > > >
> > > > The codebehind page has:
> > > >
> > > > Namespace ASPNET.StarterKit.Portal
> > > > Public Class CDefault
> > > > Inherits System.Web.UI.Page
> > > > Private Sub Page_Load(ByVal sender As System.Object, ByVal
e
> As
> > > > System.EventArgs) Handles MyBase.Load
> > > > <code here>
> > > > End Sub
> > > > End Class
> > > > End Namespace
> > > >
> > > > I'm trying to find out how and why this works the way that it

does.
> > It's
> > > > more complex than the examples given by tutorials and books.
> > > >
> > > > And again, I'm trying to figure out how the namespace declared

here
> > makes
> > > > it's way into the assembly. And because it does, somehow,
does that
> > make
> > > it
> > > > available through the entire project?
> > > >
> > > > Random
> > > >
> > > > "Marina" <so*****@nospam.com> wrote in message
> > > > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > > > First of all, namespaces can be used with the 'Imports'

keyword, so
> as
> > > not
> > > > > have to write out the full namespace for every class, not
the > > 'Inherits'
> > > > > attribute.
> > > > >
> > > > > Think of namespaces as folders in your file system, and

classes
as
> the
> > > > files
> > > > > in them. So a namespace itself isn't anything but an
organizational
> > > > > container for classes - just as a folder is just a container

for > > files.
> > > > > Classes are the actual things that you instantiate, and call
methods
> > on.
> > > > >
> > > > > I didn't really understand your questions. I think they all stem > from
> > > not
> > > > > understanding what a namespace actually is.
> > > > >
> > > > > "Random" <ci*******@hotmail.com> wrote in message
> > > > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > > > I'm confused about the proper use and usefulness of

namespaces.
I
> > > > beleive
> > > > > I
> > > > > > understand the purpose is so the developer can put classes
within
> > > > > namespaces
> > > > > > to essentially organize your code. And I understand that you > > declare
> > > > your
> > > > > > intention to use a namespace within a page through the
"Inherits"
> > > > > attribute.
> > > > > > I know that using "Inherits" isn't absolutely necessary, it's just
> > > > > > recommended so the developer doesn't have to type out the

entire
> > > > namespace
> > > > > > in code. I know that namespaces have to appear in the project > > > assembly,
> > > > > > however...
> > > > > >
> > > > > > How does the assembly find a namespace that the developer has > > > > written????
> > > > > > In all the examples I've seen, namespaces have been
written in > > > > codebehind
> > > > > > pages. How does this make them accessible to the entire
project?
> > > > What's
> > > > > to
> > > > > > prevent a duplicate namespace from being written in a

different
> > > > codebehind
> > > > > > page? Is there a better place to write all the project
namespaces
> > for
> > > > > more
> > > > > > centralized accessibility?
> > > > > >
> > > > > > And finally, how do namespaces DIFFER from classes?
> > > > > >
> > > > > > Random
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #22
You simply create a Class Library with the function(s) you want in it.
Reference the Class Library in your Page, and use it.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#k**************@TK2MSFTNGP12.phx.gbl...
hoo, boy. What a thread this is turning out to be. First, I do understand, and you have confirmed a lot of things I have suspected.

Let me take a different approach on this, if I may. Let's say I have two
aspx pages that I know I want utilize a specific function within, that is
contained in a class. Without having to copy/paste this function into a
different class in a different codebehind page (because I don't want them to have the same codebehind page), how can I reference this function.

NONE of the tutorials or materials I have read go beyond a one page example. Seperation of code and HTML... fine. It's the sharing of code through
namespaces and classes that I'm having difficulty grasping at this point.

"Kevin Spencer" <uc*@ftc.gov> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Hi Random,
I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where all these written classes are?
A .Net assembly is a compiled DLL. The data in the code files is compiled
into binary code in the DLL, including all the namespace information,
references, etc. Once compiled into a DLL, your CodeBehind class files are nothing but dead weight. They are not used; the DLL is. So, forget about

the
"written classes". Think about the classes themselves, rather than the

code
you write to create them.
As another example, what if I wrote an aspx page that inherited a class contained in a codebehind page that was NOT referenced by the aspx page?

You wouldn't be able to compile OR use it. An aspx Page is a composite of 2
distinct entities: the Page Template (.aspx) and the CodeBehind class.
The Page Template inherits the CodeBehind class, which inherits
System.Web.UI.Page. The .aspx file by itself can do nothing without
CodeBehind, whether that is in the same (.aspx) file as the Page Template, a
CodeBehind file, or a DLL. The important thing is that the .aspx Page
Template has a reference in it telling it where to look for the class
definition that it inherits. If the CodeBehind is compiled into a DLL,
and that DLL is in one of the locations that ASP.Net can find it (Global
Assembly Cache or \bin folder), ASP.Net uses Reflection to query the
assembly for the class, based upon the NameSpace and Class name of the
class. All of this information is contained in the DLL itself.
Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where
it can
be centrally referenced?


Again, only the CodeBehind is compiled. The Page Template (.aspx) must

have
a Reference in it telling it where to find the CodeBehind class. There IS not "central source" for information about .Net classes. That is why you

can
simply put your DLLs into the \bin folder of your web app, and they will

be
found. Once found, the .Net platform can query the DLLs to find the DLL
needed, and the class inside the DLL to use.

Take a look at the following example, from an ASPX page I created:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="WebForm1.aspx.vb" Inherits="ControlTest.WebForm1"%>

The "CodeBehind" attribute is there solely for the benefit of Visual
Studio.Net. It tells VS.Net what file to compile to create the DLL used by the Page class(es). The "Inherits" directive is the key. Note that it
contains no information about the location of the DLL. ASP.Net KNOWS where the DLL can be located. Instead, it contains a reference to a NameSpace

and
a class, which it can find by using Reflection on the assemblies in the

\bin
folder and the GAC.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Random" <ci*******@hotmail.com> wrote in message
news:#D**************@TK2MSFTNGP10.phx.gbl...
I know you are not trying to offend, Marina, but I am an experienced
programmer, just new to .NET, and I have read a lot, from the basics.
I am
disappointed that a lot of the 'beginner' material has been unhelpful when it comes to an architectural overview of ASP.NET, which is what I am

trying
to clarify here. I thought that by asking 'basic' questions, I might get
a
better understanding of how things fit into the whole. So please be

patient
with me in this.

I realize that while Visual Studio automatically encourages a 1 to 1
relationship between aspx and codebehind pages, this does not

necessarily need to be the case. I also realize that errors would occur during
compiling if the same class was written in different places. What I don't understand is how Visual Studio keeps track in the assembly of where
all these written classes are?

As another example, what if I wrote an aspx page that inherited a class contained in a codebehind page that was NOT referenced by the aspx page? Since the class is found in the assembly, how would the aspx page know

where
to look? When the code is all compiled, does it automatically all the
classes available from a central source? And if this is the case,

wouldn't
it make more sense to put all the code into a *.vb or *.cs file where it can
be centrally referenced?

You are right, I think there is something very simple I am

misunderstanding,
but for the life of me, I can't locate the answer anwhere.

Random

"Marina" <so*****@nospam.com> wrote in message
news:e7****************@TK2MSFTNGP12.phx.gbl...
> I have no idea what you are talking about to be honest.
>
> The class is already in a namespace - the Inherits attribute is just
> referencing. It isn't creating a new namespace or a new class. So I

have
no
> idea what you are talking about when you ask about namespaces being
written
> in central locations.
>
> You can have any number of pages inherit from the same class - as
long as
> that class actually exists. In the visual studio model, you would
have to
> manually do that, because it assume a 1 to 1 ration between pages
and code
> behind classes.
>
> If you tried to compiled two classes with the same name into the
same > assembly, the compiler would not allow you to do this. The assembly
itself
> knows what classes it has, and what namespace each one is in, in it's > manifest.
>
> I would recommend you start at the very basics of ASP.NET, it sounds

like
> you are missing some basic concept about how this all works. In your first
> post you asked about the difference between a namespace and a class - so it
> seems like you need to go to the beginning of .NET, and not just
into the
> middle of ASP.NET.
>
> "Random" <ci*******@hotmail.com> wrote in message
> news:ua**************@TK2MSFTNGP09.phx.gbl...
> > Okay, that clarifies the "Inherits" vs. "Imports" question very well. > > Thanks.
> >
> > As far as the namespace being available in the assembly, though,
let me
> give
> > you an example...
> >
> > Using the portal code I gave before, would I be able to write another aspx
> > page, use the same "Inherits=<fully qualified class name>"
phrasing, > without
> > that class being written into the different codebehind page
referenced in
> > the new aspx page?
> >
> > If yes, why? Shouldn't namespaces be written in a more centrally
> referenced
> > file?
> >
> > If no, then how can the assembly keep track of all the declared
> namespaces?
> > And what would it do if two or more codebehind references had the same > > namespace and class written in them?
> >
> > Random
> >
> > "Marina" <so*****@nospam.com> wrote in message
> > news:eq**************@TK2MSFTNGP10.phx.gbl...
> > > This inherits attribute, refers to the name of the class this page > > inherits
> > > from. The class's name is CDefault, but it is located in the
> > > ASPNET.StarterKit.Portal namespace, and so the namespace has to
preceed
> > it.
> > >
> > > At runtime, asp.net looks for a class with the name in the inherits > > > attribute.
> > >
> > > This has nothing to do with projects, or namespaces being available. It
> is
> > > just the fully qualified name of the class.
> > >
> > > "Random" <ci*******@hotmail.com> wrote in message
> > > news:OI*************@TK2MSFTNGP09.phx.gbl...
> > > > Hmm. I'm trying to teach myself from examples and tutorials and > books.
> > > > Specifically in this case, I'm trying to learn from the MS
> > > PortalStarterKit.
> > > > Specifically, the default page in that example has as the first line
> in
> > > > default.aspx:
> > > >
> > > > <%@ Page CodeBehind="Default.aspx.vb" language="vb"
> > > AutoEventWireup="false"
> > > > Inherits="ASPNET.StarterKit.Portal.CDefault" %>
> > > >
> > > > The codebehind page has:
> > > >
> > > > Namespace ASPNET.StarterKit.Portal
> > > > Public Class CDefault
> > > > Inherits System.Web.UI.Page
> > > > Private Sub Page_Load(ByVal sender As System.Object, ByVal
e
> As
> > > > System.EventArgs) Handles MyBase.Load
> > > > <code here>
> > > > End Sub
> > > > End Class
> > > > End Namespace
> > > >
> > > > I'm trying to find out how and why this works the way that it

does.
> > It's
> > > > more complex than the examples given by tutorials and books.
> > > >
> > > > And again, I'm trying to figure out how the namespace declared

here
> > makes
> > > > it's way into the assembly. And because it does, somehow,
does that
> > make
> > > it
> > > > available through the entire project?
> > > >
> > > > Random
> > > >
> > > > "Marina" <so*****@nospam.com> wrote in message
> > > > news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > > > First of all, namespaces can be used with the 'Imports'

keyword, so
> as
> > > not
> > > > > have to write out the full namespace for every class, not
the > > 'Inherits'
> > > > > attribute.
> > > > >
> > > > > Think of namespaces as folders in your file system, and

classes
as
> the
> > > > files
> > > > > in them. So a namespace itself isn't anything but an
organizational
> > > > > container for classes - just as a folder is just a container

for > > files.
> > > > > Classes are the actual things that you instantiate, and call
methods
> > on.
> > > > >
> > > > > I didn't really understand your questions. I think they all stem > from
> > > not
> > > > > understanding what a namespace actually is.
> > > > >
> > > > > "Random" <ci*******@hotmail.com> wrote in message
> > > > > news:uD**************@TK2MSFTNGP10.phx.gbl...
> > > > > > I'm confused about the proper use and usefulness of

namespaces.
I
> > > > beleive
> > > > > I
> > > > > > understand the purpose is so the developer can put classes
within
> > > > > namespaces
> > > > > > to essentially organize your code. And I understand that you > > declare
> > > > your
> > > > > > intention to use a namespace within a page through the
"Inherits"
> > > > > attribute.
> > > > > > I know that using "Inherits" isn't absolutely necessary, it's just
> > > > > > recommended so the developer doesn't have to type out the

entire
> > > > namespace
> > > > > > in code. I know that namespaces have to appear in the project > > > assembly,
> > > > > > however...
> > > > > >
> > > > > > How does the assembly find a namespace that the developer has > > > > written????
> > > > > > In all the examples I've seen, namespaces have been
written in > > > > codebehind
> > > > > > pages. How does this make them accessible to the entire
project?
> > > > What's
> > > > > to
> > > > > > prevent a duplicate namespace from being written in a

different
> > > > codebehind
> > > > > > page? Is there a better place to write all the project
namespaces
> > for
> > > > > more
> > > > > > centralized accessibility?
> > > > > >
> > > > > > And finally, how do namespaces DIFFER from classes?
> > > > > >
> > > > > > Random
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #23

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: Random | last post by:
I'm confused about the proper use and usefulness of namespaces. I beleive I understand the purpose is so the developer can put classes within namespaces to essentially organize your code. And I...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.