Re: Namespaces - broad question
From: Kevin Spencer (uce_at_ftc.gov)
Date: 04/08/04
- Next message: Bin Song, MCP: "RE: bind datagrid to dataset filled at runtime"
- Previous message: Sueffel: "Frames"
- In reply to: Random: "Re: Namespaces - broad question"
- Next in thread: Random: "Re: Namespaces - broad question"
- Reply: Random: "Re: Namespaces - broad question"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 8 Apr 2004 16:03:57 -0400
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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
- Next message: Bin Song, MCP: "RE: bind datagrid to dataset filled at runtime"
- Previous message: Sueffel: "Frames"
- In reply to: Random: "Re: Namespaces - broad question"
- Next in thread: Random: "Re: Namespaces - broad question"
- Reply: Random: "Re: Namespaces - broad question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
