automatic namespace importing

N

Natan

Juan said:
Natan,

Could you let me know how you determined that

Really, I don't remember. Probably i just figured out. But it's just how
asp.net works. It parses the ASPX page and creates a class.
Where did you find the list of Imports statements you quoted ? ....
I did that and got this list of compiled page resources
in the "Complete Compilation Source" :

System.EnterpriseServices.dll
acme.dll
global.asaxxi3ltqav.dll
System.Web.Services.dll
System.dll
System.Drawing.dll
System.Web.dll
System.Data.dll
mscorlib.dll
System.Web.Mobile.dll
System.Xml.dll
i8fuexe.dll
i8fuexe.0.cs
i8fuexe.1.cs


Close! Very close :p
There are two links in the error page. You probably opened the first,
and those are the assemblies your page is linked against. In case you
don't find it, run some aspx files in your IIS, then take a look at your
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files

ASP.NET should keep cache of compiled pages in that directory. (you can
find this dir in the end of the compilation line you got this
assemblies). Enter any application folder, then there are some folders
with random names. Open them, you will end up in a directory with lots
of files, some of them are .CS.

Open any CS, you will see that it is the class ASP.NET parser generates
for every ASPX page. There are some .cmdline that are the command line
used to compile the class. After compiling the page, asp.net uses the
compiled assembly to show the page. (even though you compiled your
webapp with code behind, aspx pages are still compilled individually
when they run, extending the base class)

See, there is a difference in linking libraries and importing
namespaces. The reason you didn't see difference in the reference list
is because System.Diagnostic namespace is half in mscorlib.dll and half
in System.dll, that are already included in the list of references.
Namespaces do not map to assemblies directly. e.g. most of "System"
namespace is in mscorlib.dll, not in System.dll. All the namespaces in
..NET BCL are included in something like 8 DLLs.

using directive only tell the compiler what namespaces to look for
types, linking libraries tell in what assemblies he should look for
namespaces.

@ Import directive is just a way to include another "using" in the
generated class, because every "script runat='server' block is put
inside the page class where you can't insert any using directive. e.g.,
if you have an @Import directive to a namespace, but the assembly you
are linking to is neither in bin nor in GAC, the compiler will raise an
error that it cannot load the namespace.

To explain my point, I must tell you why it is important to me to
automatically import namespaces in aspx files. I prefer to work with
"script runat='server'" and not code behind because:

1. VS.NET html editor sucks in a way i can't even describe it
2. VS.NET is against XHTML
3. VS.NET and most of WebControls are against CSS and "tableless"
standards and principles
4. It is much easier to work with code and html in the same page. I can
control how things are done and it's much easier than old asp (in
vs.net, everything must be done twice with code behind and even though
it generates the code, you must use the designer to create everything,
what is less productive if you know html and know what you are doing)
5. I don't have to use most of WebControls since HtmlControls work
perfectly fine and are much better to create cross browser applications.
You will notice 70% of webcontrols were created to make vs.net work in
design time, but they are not needed at all.
6. I don't have to worry about design time support. I worked with html
my entire life and it is much easier to write
<div id='div' runat='server'></div> than drag and dropping asp:panels
that render divs anyway.
7. I don't have to deal with front page extensions, my directory tree is
always clean and have only what it needs, no need to export to another
directory.

So, the fact is that i hardly use code behind. I like my UltraEdit or
dreamweaver for pages, and keep VS to create the libraries. That's why I
need to <%@ Import %> one or two namespaces in my class. At least the
business logic and entities namespace must be available to pages since
they call methods to databind and other stuff. All the heavy logic are
stored in dlls, so i don't need to worry about people looking at my code.

Well... back to the subject.

I attached to this post the output generated by asp.net parser, cached
in Temporary ASP.NET Files, and the command line used to compile, so if
you don't find it, here is your reference.

Note the "public class bla_aspx : System.Web.UI.Page" because the page
is named "bla.aspx", and the "script runat='server'" in the middle of
the class, where the parses puts it. If you use code behind, what
happens is that this class uses your class as base class, not Page.

I suggest you to put some html, some runat='server' controls and see
what is the output in the class. It's good to understand how it really
works.
If I did *not* understand what you said, please detail the method(s)
you used to determine which dll's are included in the compiled aspx page,
and how/when/where another namespace, added via <%@ Import Namespace
="Bla.Bla" %>
to the page, is added to the compiled list of resources for that page.
This will make your position a bit easier to understand.
Please take the time to document this, as I have done.

Don't take offense. Just prove your point.
This is extremely interesting, and I'd like to know
if you are actually right, because it would certainly
change the way I've understood, up until now,
the .NET Framework and ASP.NET's inner workings.

I'm not an MVP... :p but this is just how it works. take a tour in
system.web.dll, in System.Web.Compilation through ildasm and you will
see some classes that does the parsing and compiling. probably there is
something in MSDN about this stuff.

I hope it helps to prove my point.

You can send me an email if you want. Just take the "-list" part off my
email.

[]'s

//------------------------------------------------------------------------------
// <autogenerated>
// This code was generated by a tool.
// Runtime Version: 1.1.4322.2032
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </autogenerated>
//------------------------------------------------------------------------------

namespace ASP {
using System;
using System.Collections;
using System.Collections.Specialized;
using System.Configuration;
using System.Text;
using System.Text.RegularExpressions;
using System.Web;
using System.Web.Caching;
using System.Web.SessionState;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;


[System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
public class bla_aspx : System.Web.UI.Page, System.Web.SessionState.IRequiresSessionState {

private static int __autoHandlers;

private static bool __initialized = false;

private static System.Collections.ArrayList __fileDependencies;


#line 2 "D:\Root\bla.aspx"

void Page_Load(object sender, EventArgs e)
{
bla
}

#line default
#line hidden

public bla_aspx() {
System.Collections.ArrayList dependencies;
if ((ASP.bla_aspx.__initialized == false)) {
dependencies = new System.Collections.ArrayList();
dependencies.Add("D:\\Root\\bla.aspx");
ASP.bla_aspx.__fileDependencies = dependencies;
ASP.bla_aspx.__initialized = true;
}
this.Server.ScriptTimeout = 30000000;
}

protected override int AutoHandlers {
get {
return ASP.bla_aspx.__autoHandlers;
}
set {
ASP.bla_aspx.__autoHandlers = value;
}
}

protected System.Web.HttpApplication ApplicationInstance {
get {
return ((System.Web.HttpApplication)(this.Context.ApplicationInstance));
}
}

public override string TemplateSourceDirectory {
get {
return "/";
}
}

private void __BuildControlTree(System.Web.UI.Control __ctrl) {
}

protected override void FrameworkInitialize() {
this.__BuildControlTree(this);
this.FileDependencies = ASP.bla_aspx.__fileDependencies;
this.EnableViewStateMac = true;
this.Request.ValidateInput();
}

public override int GetTypeHashCode() {
return 5381;
}
}
}

/t:library /utf8output /R:"c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll" /R:"c:\windows\assembly\gac\system.enterpriseservices\1.0.5000.0__b03f5f7f11d50a3a\system.enterpriseservices.dll" /R:"c:\windows\microsoft.net\framework\v1.1.4322\temporary asp.net files\root\78f3146f\a4b7e5c9\assembly\dl2\d7d24fd5\102994f1_06a6c401\chat2.dll" /R:"c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.data.dll" /R:"c:\windows\assembly\gac\system.web.mobile\1.0.5000.0__b03f5f7f11d50a3a\system.web.mobile.dll" /R:"c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system.drawing.dll" /R:"c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.dll" /R:"c:\windows\assembly\gac\system.web.services\1.0.5000.0__b03f5f7f11d50a3a\system.web.services.dll" /R:"c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll" /R:"c:\windows\assembly\gac\system.web\1.0.5000.0__b03f5f7f11d50a3a\system.web.dll" /out:"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\root\78f3146f\a4b7e5c9\djudr-s0.dll" /D:DEBUG /debug+ /optimize- /warnaserror /w:1 "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\root\78f3146f\a4b7e5c9\djudr-s0.0.cs"
 
J

Juan T. Llibre [MVP]

I think we may be nearer to narrowing down
what is happening here.

What is included in that file you sent :
// <autogenerated>
// This code was generated by a tool.
// Runtime Version: 1.1.4322.2032
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </autogenerated>

is autogenerated by the csc compiler, *not* by the ASP.NET
engine, which directly contradicts your statement that :
Those are generated automatically by ASP.NET
when it parses the page and creates the class.

That generated output is *not* the result of parsing and compiling
the page by ASP.NET, but the result of the csc.exe compiler
compiling the page, just as it would have been the result of the
vbc.exe compiler, if VB had been the language declared in the page.

I have quite an interesting .NET/ASP.NET setup, because I'm running
Windows Server 2003, which includes .Net Framework 1.1 "out of the box",
which means I didn't have to install it.

I afterwards installed VS.NET 2005, which installed .Net Framework 2.0.

Here's the interesting thing :

I've *never* compiled any .NET 1.1.4322.2032 projects
( like for example, the ASP.NET Forums... ) with VS.NET 2005.

If I did that, the projects would get updated to VS.NET 2005 format,
and that would ruin the possibilities of maintaining them as ASP.NET 1.1 projects.

Here's the key:

I did a search for source files ( .vb or .cs ) of the type which have the
"This code was generated by a tool" disclaimer, in the "Temporary ASP.NET files"
folder, and *only* found files generated by VS.NET 2005 with this disclaimer :

"This code was generated by a tool.
Runtime Version:2.0.40607.16"

I did *not* find any files with the disclaimer for "Runtime Version 1.1.4322.2032",
even though they were equally processed by ASP.NET.

*No* .cs or .vb files for the runtime version 1.1.4322.2032 were found in the "Temporary ASP.NET files
folder" for the .Net Framework 1.1.4322.2032 *even though they had been *equally* processed by ASP.NET*.

This leads to the inescapable conclusion that it is *not*
ASP.NET which is compiling the .aspx files, as you claim,
and that it *is* the underlying compiler ( csc.exe or vbc.exe )
which is doing the compiling, the results of which *then* are
processed by aspnet_isapi.dll.

re:
it's just how asp.net works.
It parses the ASPX page and creates a class.

No. The aspx page is compiled by either csc.exe or vbc.exe,
depending on the language declared for the page, and ASP.NET
( aspnet_isapi.dll ) has nothing to do with the code until it processes
the MSIL generated by the appropiate compiler.

Your turn...



Juan T. Llibre
===========
Natan said:
Juan said:
Natan,

Could you let me know how you determined that

Really, I don't remember. Probably i just figured out. But it's just how
asp.net works. It parses the ASPX page and creates a class.
Where did you find the list of Imports statements you quoted ? ...
I did that and got this list of compiled page resources
in the "Complete Compilation Source" :

System.EnterpriseServices.dll
acme.dll
global.asaxxi3ltqav.dll
System.Web.Services.dll
System.dll
System.Drawing.dll
System.Web.dll
System.Data.dll
mscorlib.dll
System.Web.Mobile.dll
System.Xml.dll
i8fuexe.dll
i8fuexe.0.cs
i8fuexe.1.cs


Close! Very close :p
There are two links in the error page. You probably opened the first,
and those are the assemblies your page is linked against. In case you
don't find it, run some aspx files in your IIS, then take a look at your
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files

ASP.NET should keep cache of compiled pages in that directory. (you can
find this dir in the end of the compilation line you got this
assemblies). Enter any application folder, then there are some folders
with random names. Open them, you will end up in a directory with lots
of files, some of them are .CS.

Open any CS, you will see that it is the class ASP.NET parser generates
for every ASPX page. There are some .cmdline that are the command line
used to compile the class. After compiling the page, asp.net uses the
compiled assembly to show the page. (even though you compiled your
webapp with code behind, aspx pages are still compilled individually
when they run, extending the base class)

See, there is a difference in linking libraries and importing
namespaces. The reason you didn't see difference in the reference list
is because System.Diagnostic namespace is half in mscorlib.dll and half
in System.dll, that are already included in the list of references.
Namespaces do not map to assemblies directly. e.g. most of "System"
namespace is in mscorlib.dll, not in System.dll. All the namespaces in
.NET BCL are included in something like 8 DLLs.

using directive only tell the compiler what namespaces to look for
types, linking libraries tell in what assemblies he should look for
namespaces.

@ Import directive is just a way to include another "using" in the
generated class, because every "script runat='server' block is put
inside the page class where you can't insert any using directive. e.g.,
if you have an @Import directive to a namespace, but the assembly you
are linking to is neither in bin nor in GAC, the compiler will raise an
error that it cannot load the namespace.

To explain my point, I must tell you why it is important to me to
automatically import namespaces in aspx files. I prefer to work with
"script runat='server'" and not code behind because:

1. VS.NET html editor sucks in a way i can't even describe it
2. VS.NET is against XHTML
3. VS.NET and most of WebControls are against CSS and "tableless"
standards and principles
4. It is much easier to work with code and html in the same page. I can
control how things are done and it's much easier than old asp (in
vs.net, everything must be done twice with code behind and even though
it generates the code, you must use the designer to create everything,
what is less productive if you know html and know what you are doing)
5. I don't have to use most of WebControls since HtmlControls work
perfectly fine and are much better to create cross browser applications.
You will notice 70% of webcontrols were created to make vs.net work in
design time, but they are not needed at all.
6. I don't have to worry about design time support. I worked with html
my entire life and it is much easier to write
<div id='div' runat='server'></div> than drag and dropping asp:panels
that render divs anyway.
7. I don't have to deal with front page extensions, my directory tree is
always clean and have only what it needs, no need to export to another
directory.

So, the fact is that i hardly use code behind. I like my UltraEdit or
dreamweaver for pages, and keep VS to create the libraries. That's why I
need to <%@ Import %> one or two namespaces in my class. At least the
business logic and entities namespace must be available to pages since
they call methods to databind and other stuff. All the heavy logic are
stored in dlls, so i don't need to worry about people looking at my code.

Well... back to the subject.

I attached to this post the output generated by asp.net parser, cached
in Temporary ASP.NET Files, and the command line used to compile, so if
you don't find it, here is your reference.

Note the "public class bla_aspx : System.Web.UI.Page" because the page
is named "bla.aspx", and the "script runat='server'" in the middle of
the class, where the parses puts it. If you use code behind, what
happens is that this class uses your class as base class, not Page.

I suggest you to put some html, some runat='server' controls and see
what is the output in the class. It's good to understand how it really
works.
If I did *not* understand what you said, please detail the method(s)
you used to determine which dll's are included in the compiled aspx page,
and how/when/where another namespace, added via <%@ Import Namespace
="Bla.Bla" %>
to the page, is added to the compiled list of resources for that page.
This will make your position a bit easier to understand.
Please take the time to document this, as I have done.

Don't take offense. Just prove your point.
This is extremely interesting, and I'd like to know
if you are actually right, because it would certainly
change the way I've understood, up until now,
the .NET Framework and ASP.NET's inner workings.

I'm not an MVP... :p but this is just how it works. take a tour in
system.web.dll, in System.Web.Compilation through ildasm and you will
see some classes that does the parsing and compiling. probably there is
something in MSDN about this stuff.

I hope it helps to prove my point.

You can send me an email if you want. Just take the "-list" part off my
email.

[]'s


--------------------------------------------------------------------------------


//------------------------------------------------------------------------------
// <autogenerated>
// This code was generated by a tool.
// Runtime Version: 1.1.4322.2032
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </autogenerated>
//------------------------------------------------------------------------------

namespace ASP {
using System;
using System.Collections;
using System.Collections.Specialized;
using System.Configuration;
using System.Text;
using System.Text.RegularExpressions;
using System.Web;
using System.Web.Caching;
using System.Web.SessionState;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;


[System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
public class bla_aspx : System.Web.UI.Page, System.Web.SessionState.IRequiresSessionState {

private static int __autoHandlers;

private static bool __initialized = false;

private static System.Collections.ArrayList __fileDependencies;


#line 2 "D:\Root\bla.aspx"

void Page_Load(object sender, EventArgs e)
{
bla
}

#line default
#line hidden

public bla_aspx() {
System.Collections.ArrayList dependencies;
if ((ASP.bla_aspx.__initialized == false)) {
dependencies = new System.Collections.ArrayList();
dependencies.Add("D:\\Root\\bla.aspx");
ASP.bla_aspx.__fileDependencies = dependencies;
ASP.bla_aspx.__initialized = true;
}
this.Server.ScriptTimeout = 30000000;
}

protected override int AutoHandlers {
get {
return ASP.bla_aspx.__autoHandlers;
}
set {
ASP.bla_aspx.__autoHandlers = value;
}
}

protected System.Web.HttpApplication ApplicationInstance {
get {
return ((System.Web.HttpApplication)(this.Context.ApplicationInstance));
}
}

public override string TemplateSourceDirectory {
get {
return "/";
}
}

private void __BuildControlTree(System.Web.UI.Control __ctrl) {
}

protected override void FrameworkInitialize() {
this.__BuildControlTree(this);
this.FileDependencies = ASP.bla_aspx.__fileDependencies;
this.EnableViewStateMac = true;
this.Request.ValidateInput();
}

public override int GetTypeHashCode() {
return 5381;
}
}
}
 
N

Natan

Juan said:
I think we may be nearer to narrowing down
what is happening here.


That generated output is *not* the result of parsing and compiling
the page by ASP.NET, but the result of the csc.exe compiler
compiling the page, just as it would have been the result of the
vbc.exe compiler, if VB had been the language declared in the page.

Ok. Now think in what you said. Does it really make sense? "lets include
an html parser in the C# compiler"... i don't think so.

Yes, CSC compiles the code, but doesn't generates this class from html.
This is because it is specific to ASP.NET how it parses the page and
creates the class. CSC's job is just to compile C# code, nothing more.

There are some classes in .NET that generates code from xml, and this is
probaly generated by them. But who parses the html and generates the
input to this tool is ASP.NET. Because ASP.NET is responsible for this,
not CSC.
I have quite an interesting .NET/ASP.NET setup, because I'm running
Windows Server 2003, which includes .Net Framework 1.1 "out of the box",
which means I didn't have to install it.

Yes, because Win2003 comes with .NET 1.1.
I afterwards installed VS.NET 2005, which installed .Net Framework 2.0.

Here's the interesting thing :

I've *never* compiled any .NET 1.1.4322.2032 projects
( like for example, the ASP.NET Forums... ) with VS.NET 2005.

1.1.4322.2032 is the version of .NET 1.1 SP1, not VS.NET 2005.
Here's the key:

I did a search for source files ( .vb or .cs ) of the type which have the
"This code was generated by a tool" disclaimer, in the "Temporary
ASP.NET files"
folder, and *only* found files generated by VS.NET 2005 with this
disclaimer :

"This code was generated by a tool.
Runtime Version:2.0.40607.16"

So, here we go. Please, forget about VS.NET. .NET doesn't depend on
VS.NET to work. It is just a tool to help you create applications.

You got this because you installed .NET 2.0. After installing it, all
your asp.net pages are compiled with .net 2.0. You can change this in
your website properties in IIS.
I did *not* find any files with the disclaimer for "Runtime Version
1.1.4322.2032",
even though they were equally processed by ASP.NET.

Because it is processed by .NET 2.0 =)
This leads to the inescapable conclusion that it is *not*
ASP.NET which is compiling the .aspx files, as you claim,
and that it *is* the underlying compiler ( csc.exe or vbc.exe )
which is doing the compiling, the results of which *then* are
processed by aspnet_isapi.dll.

I can't understand how you got to this conclusion. "the numer is 2, not
1.. so csc is an html parser". this doesn't make sense.

What you discovered is that your code is generated by a different
version of the same tool, but you didn't see anything telling that csc
is parsin html pages.

When I tell you ASP.NET parses the page to generate the class, the real
process probably involves lots of classes in Microsoft.CSharp too. But
the one who parses the html and tell how to create the class is ASP.NET.
That is why you have System.Web.Compilation...
No. The aspx page is compiled by either csc.exe or vbc.exe,
depending on the language declared for the page, and ASP.NET
( aspnet_isapi.dll ) has nothing to do with the code until it processes
the MSIL generated by the appropiate compiler.

Of course it is compiled by csc. But not generated. That is why csc is
called "c sharp compiler" not "asp.net html parser".


Take a loot at this and this is probably how things work.
http://myxaml.com/marcclifton/archive/2004/04/21/223.aspx

so asp.net generates common input to some parser which given an language
type generates the real output. csc only compiles it.

[Tired...]
 
J

Juan T. Llibre [MVP]

Natan,

Here's the sequence of events when an .aspx page is called:

1. Generation of a *.cs or .vb file holding code that matches the ASPX declarations.

2. Using of csc.exe (C# compiler) to compile *.cs file into DLL
or using of vbc.exe (VB.NET compiler) to compile *.vb file into DLL

You can see csc.exe or vbc.exe if you monitor the running processes
with Task Manager or any other process explorer. Try it, and see.

3. Running of the compiled page assembly

This sequence occurs just once, resulting in a DLL that will be used for other requests
until one of the page dependencies files are changed, leading to re-compilation.

Think of ASP.NET (aspnet_isapi.dll, w3wp.exe, aspnet_wp.exe, etc. ) as a "traffic policeman", directing the various components
of the .NET Framework which result in compiled pages but, please, don't think that ASP.NET compiles anything,
except in the loosest of interpretations.

The best explanation ( Dino Exposito's excellent article )
I've ever read about the ASP.NET HTTP Runtime is at :

http://msdn.microsoft.com/library/d...-us/dnaspp/html/dngrfTheASPNETHTTPRuntime.asp

Look for the subject heading : Temporary Files and Page Assemblies

And you'll see that it is "the HTTP infrastructure which parses the source code of the .aspx file,
creates a C# or Visual Basic .NET class (depending on the language set on the .aspx page),
and compiles it on the fly".

Dino explains the ASP.NET process splendidly in the heading:
*Components of the ASP.NET Infrastructure*

"The ASP.NET ISAPI extension is a Win32 DLL and does not host managed code.
It is the central console that receives and dispatches requests for a variety of ASP.NET resources. "

The specific .NET Framework class which handles reception and dispatch of requests is System.Web.HttpApplication,
called by the ASP.NET runtime environment ( aspnet_isapi.dll, aspnet_wp.exe, aspnet_filter.dll, and aspnet_state.exe for IIS 5,
and aspnet_isapi.dll, w3wp.exe, aspnet_filter.dll, and aspnet_state.exe for IIS 6. ).

It is the common language runtime (CLR) which runs managed code.

Even the simplest thing about ASP.NET, the recognition of an aspx request,
is handled by System.Web.UI.PageHandlerFactory ( a.NET Framework Class ),
and not by ASP.NET itself.

The aspx page parsing, which you insist is done by ASP.NET,
is actually carried out by System.Web.UI.PageParser, which is another ..NET Framework class.

ASP.NET neither parses nor compiles. It *calls* the appropiate .NET Framework classes and compilers.



Juan T. Llibre
===========
Natan said:
Juan said:
I think we may be nearer to narrowing down
what is happening here.


That generated output is *not* the result of parsing and compiling
the page by ASP.NET, but the result of the csc.exe compiler
compiling the page, just as it would have been the result of the
vbc.exe compiler, if VB had been the language declared in the page.

Ok. Now think in what you said. Does it really make sense? "lets include
an html parser in the C# compiler"... i don't think so.

Yes, CSC compiles the code, but doesn't generates this class from html.
This is because it is specific to ASP.NET how it parses the page and
creates the class. CSC's job is just to compile C# code, nothing more.

There are some classes in .NET that generates code from xml, and this is
probaly generated by them. But who parses the html and generates the
input to this tool is ASP.NET. Because ASP.NET is responsible for this,
not CSC.
I have quite an interesting .NET/ASP.NET setup, because I'm running
Windows Server 2003, which includes .Net Framework 1.1 "out of the box",
which means I didn't have to install it.

Yes, because Win2003 comes with .NET 1.1.
I afterwards installed VS.NET 2005, which installed .Net Framework 2.0.

Here's the interesting thing :

I've *never* compiled any .NET 1.1.4322.2032 projects
( like for example, the ASP.NET Forums... ) with VS.NET 2005.

1.1.4322.2032 is the version of .NET 1.1 SP1, not VS.NET 2005.
Here's the key:

I did a search for source files ( .vb or .cs ) of the type which have the
"This code was generated by a tool" disclaimer, in the "Temporary
ASP.NET files"
folder, and *only* found files generated by VS.NET 2005 with this
disclaimer :

"This code was generated by a tool.
Runtime Version:2.0.40607.16"

So, here we go. Please, forget about VS.NET. .NET doesn't depend on
VS.NET to work. It is just a tool to help you create applications.

You got this because you installed .NET 2.0. After installing it, all
your asp.net pages are compiled with .net 2.0. You can change this in
your website properties in IIS.
I did *not* find any files with the disclaimer for "Runtime Version
1.1.4322.2032",
even though they were equally processed by ASP.NET.

Because it is processed by .NET 2.0 =)
This leads to the inescapable conclusion that it is *not*
ASP.NET which is compiling the .aspx files, as you claim,
and that it *is* the underlying compiler ( csc.exe or vbc.exe )
which is doing the compiling, the results of which *then* are
processed by aspnet_isapi.dll.

I can't understand how you got to this conclusion. "the numer is 2, not
1.. so csc is an html parser". this doesn't make sense.

What you discovered is that your code is generated by a different
version of the same tool, but you didn't see anything telling that csc
is parsin html pages.

When I tell you ASP.NET parses the page to generate the class, the real
process probably involves lots of classes in Microsoft.CSharp too. But
the one who parses the html and tell how to create the class is ASP.NET.
That is why you have System.Web.Compilation...
No. The aspx page is compiled by either csc.exe or vbc.exe,
depending on the language declared for the page, and ASP.NET
( aspnet_isapi.dll ) has nothing to do with the code until it processes
the MSIL generated by the appropiate compiler.

Of course it is compiled by csc. But not generated. That is why csc is
called "c sharp compiler" not "asp.net html parser".


Take a loot at this and this is probably how things work.
http://myxaml.com/marcclifton/archive/2004/04/21/223.aspx

so asp.net generates common input to some parser which given an language
type generates the real output. csc only compiles it.

[Tired...]
 
N

Natan

Please, let`s make things clear...

First, we are talking about the same thing. And we agree in the same
points, there are no need for this debate.

Second, ASP.NET is the System.Web namespace. You said: "The aspx page
parsing, which you insist is done by ASP.NET, is actually carried out by
System.Web.UI.PageParser, which is another .NET Framework class."

You are right and I'm right. PageParser is a class in .NET as any other
class, but since everything inside System.Web namespace is related to
asp.net, when I say "asp.net parses the page", it is because there are
some classes in System.Web that handle all the processing of turning the
HTML code into code that is used to generate DLL.

And when I say "asp.net parses the aspx page" is different than "asp.net
compiles the page". All the parsing i'm talking about happens BEFORE
your item 1 finishes.

The rest of the processing is documented in .NET and what you said here
is exactly what i said before. Take a look at the previous messages and
you will see that what YOU said is that csc compiles the aspx page, and
i said the csc compiles the output that asp.net generates from the html
page. It is the same, you only jumped a few steps.

The problem here is that you think of ASP.NET as a bunch of dlls and
exes that IIS uses to talk to .NET while I think of ASP.NET as a
platform to delelop web applications using .NET, that includes not only
those files, but the whole System.Web namespace and everything related
that make things work. That'`s why you never agree with me and I never
agree with you.

I'm tired of the discussion. We are talking about the same thing, and
the original question has nothing to do with this discussion.

So let's top here. Think about my point of view, i think about yours and
we both learn a little bit ok?

[]`s
 
J

Juan T. Llibre [MVP]

re:
ASP.NET is the System.Web namespace.

FWIW,

I think you're oversimplifying the picture.

If you believe that System.Web *is* ASP.NET, check out
http://www.csharpfriends.com/quicks...ser/vb/classbrowser.aspx?namespace=System.Web
and see how much of ASP.NET is missing from the System.Web class

It's a *lot*.

If you think about ASP.NET more in terms of a "traffic cop",
processing requests and responses to the different components
of the whole platform, you'll be closer to the truth.

re:
The problem here is that you think of ASP.NET
as a bunch of dlls and exes that IIS uses to talk to .NET

That's exactly what it is.

ASP.NET is an ISAPI application which sits between IIS
and the end user, and intercepts/requests/dispatches data
streams between them, calling components to process them.

The ASP.NET runtime environment is composed of only 4 parts :
aspnet_isapi.dll, aspnet_wp.exe, aspnet_filter.dll, and aspnet_state.exe for IIS 5,
and aspnet_isapi.dll, w3wp.exe, aspnet_filter.dll, and aspnet_state.exe for IIS 6.

The rest of the work is handled by the CLR, the .NET Framework and IIS.

re:
i said the csc compiles the output that asp.net generates from the html page.

That's where the line becomes blurry.

ASP.NET does *not* "generate* anything.
It calls resources which do the generating, i.e. acts as the "traffic cop" alluded to earlier.

A fine line separates that from what you are saying...but it's a line nonetheless.

That having been said, this discussion has gone on long enough,
and we might be tiring the rest of the frequenters to this newsgroup.

If you feel the need to specify anything else, go ahead.

I've stated everything that I thought needed specifying.




Juan T. Llibre
===========
Natan said:
Please, let`s make things clear...

First, we are talking about the same thing. And we agree in the same
points, there are no need for this debate.

Second, ASP.NET is the System.Web namespace. You said: "The aspx page
parsing, which you insist is done by ASP.NET, is actually carried out by
System.Web.UI.PageParser, which is another .NET Framework class."

You are right and I'm right. PageParser is a class in .NET as any other
class, but since everything inside System.Web namespace is related to
asp.net, when I say "asp.net parses the page", it is because there are
some classes in System.Web that handle all the processing of turning the
HTML code into code that is used to generate DLL.

And when I say "asp.net parses the aspx page" is different than "asp.net
compiles the page". All the parsing i'm talking about happens BEFORE
your item 1 finishes.

The rest of the processing is documented in .NET and what you said here
is exactly what i said before. Take a look at the previous messages and
you will see that what YOU said is that csc compiles the aspx page, and
i said the csc compiles the output that asp.net generates from the html
page. It is the same, you only jumped a few steps.

The problem here is that you think of ASP.NET as a bunch of dlls and
exes that IIS uses to talk to .NET while I think of ASP.NET as a
platform to delelop web applications using .NET, that includes not only
those files, but the whole System.Web namespace and everything related
that make things work. That'`s why you never agree with me and I never
agree with you.

I'm tired of the discussion. We are talking about the same thing, and
the original question has nothing to do with this discussion.

So let's top here. Think about my point of view, i think about yours and
we both learn a little bit ok?

[]`s
 
R

Ravichandran J.V.

You are obviously referring to VS.Net. FYI, only after creating a
project does the web.config get created so it does not really make sense
to provide for default namespaces because the project would already have
been created by VS.Net.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
G

Guest

Hi Juan,
I think I should give a helping hand for Natan a bit here. The answers
that were provided are not helpful for Natan because he is looking for a way
to create aspx pages without the help of VS.NET , but the solutions provided
by the replies are all are for creating a VS.NET template which when used
will produce a skelital code page in the project.

Now to come to Natan, I dont think there is any option present as of yet for
ver 1.1 to have what you want Natan. I havent looked into v 2.0 yet, and if
they are bringing that functionality again, it sure is going to be a lot
useful.

Have a nice day.

Regards,
CC
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top