Re: Namespaces - broad question

From: Kevin Spencer (uce_at_ftc.gov)
Date: 04/08/04 

Date: Thu, 8 Apr 2004 17:21:00 -0400

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" <cipherlad@hotmail.com> wrote in message
news:#kdV3paHEHA.3240@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" <uce@ftc.gov> wrote in message
> news:%23ZasEUaHEHA.308@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" <cipherlad@hotmail.com> wrote in message
> > news:#DVrHZZHEHA.2624@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" <someone@nospam.com> wrote in message
> > > news:e7UIi%23YHEHA.4032@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" <cipherlad@hotmail.com> wrote in message
> > > > news:uau2myYHEHA.3032@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" <someone@nospam.com> wrote in message
> > > > > news:eqT6TmYHEHA.2668@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" <cipherlad@hotmail.com> wrote in message
> > > > > > news:OI$efeYHEHA.548@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" <someone@nospam.com> wrote in message
> > > > > > > news:%23WIkSAYHEHA.2260@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" <cipherlad@hotmail.com> wrote in message
> > > > > > > > news:uD4r44XHEHA.2668@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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages