G
Geoff
Hi. I'm very confused about what gets compiled to what, and what gets
cached where, and what gets persisted, and what is shared between
users. Could someone possibly check my understanding of the process
and tell me where I'm going wrong, and answer the following questions?
I think some clear answers would benefit a lot of people here:
At runtime, when a browser request comes in, the ASP.NET (.aspx) page
is converted dynamically into a (.cs) class file. All the C# code and
the HTML in the ASPX page becomes part of the class file. (The HTML
elements are stored in strings.) This entire file is then dynamically
compiled into a Microsoft Intermediate Language File having a .DLL
extension. This is a binary file, but it does not contain native
(machine) code. It contains MSIL code. After this compilation if
there were no compilation errors, the source (.cs) file is deleted.
Instead of executing the ASPX page, the CLR actually executes the code
in the compiled DLL file corresponding to the ASPX page. The compiled
DLL file is placed by ASP.NET into a special directory structure
within the Temporary ASP.NET Files directory. The MSIL (DLL) file is
then loaded into memory and methods in the file are invoked. As each
method is invoked the CLR just-in-time compiles the method from MSIL
into native machine code.
If user 1 requests a .aspx page (HomePage.aspx), and invokes one of
the methods in that page (HelloWorld()), I understand that the .aspx
to .cs conversion will occur, and the .cs file will be compiled into a
DLL, and the DLL will be loaded into memory, and the HelloWorld()
method will be JITed into native machine code, and cached in memory,
so subsequent requests to the method will run more quickly.
Question 1. Let's say user 2, from a new browser, now requests the
same page and activates the same method. What benefit is there to
user 2? The conversion step from .aspx to .cs has already been
performed. And the compile from the .cs file to MSIL DLL step has
been performed. But what about the Just In Time compile of the
method? Does this have to be done again for user 2, since he is
running in a separate process space? Or is the Native code persisted
somewhere on disk or available somewhere in memory, such that user 2
can skip the JIT step also?
Question 2. Ngen.exe is used to pre-JIT a MSIL DLL file into a (?
extension) native machine file. But does Ngen.exe have anything to do
with the .aspx to .cs conversion step or the .cs to MSIL DLL step? Or
can I only Ngen the code behind file?
Question 3. Jeffrey Richter in his article at
"http://www.codeguru.com/Csharp/.NET/net_general/toolsand3rdparty/article.php/c4651/"
says "assemblies can be loaded in a domain-neutral or
non-domain-neutral fashion. NGen.exe produces code that assumes that
the only assembly loaded in a domain-neutral fashion is MSCorLib.dll
(which contains the definition for Object, Int32, String, and more).
If, at runtime, it is the case that other assemblies are loaded in a
domain neutral fashion, the CLR cannot use code produced by NGen.exe
and will resort to JIT compilation. For ASP.NET applications (Web
Forms and XML Web services), ***strongly-named*** assemblies are
always loaded in a domain-neutral fashion and therefore they gain no
performance benefit from having a corresponding NGen'd file."
Is this saying that ngen is useless for basically **ALL** ASP.NET
applications?
Question 4. Is there any utility or automated way to automatically
perform the .aspx to .cs conversion and the .cs to MSIL DLL step?
cached where, and what gets persisted, and what is shared between
users. Could someone possibly check my understanding of the process
and tell me where I'm going wrong, and answer the following questions?
I think some clear answers would benefit a lot of people here:
At runtime, when a browser request comes in, the ASP.NET (.aspx) page
is converted dynamically into a (.cs) class file. All the C# code and
the HTML in the ASPX page becomes part of the class file. (The HTML
elements are stored in strings.) This entire file is then dynamically
compiled into a Microsoft Intermediate Language File having a .DLL
extension. This is a binary file, but it does not contain native
(machine) code. It contains MSIL code. After this compilation if
there were no compilation errors, the source (.cs) file is deleted.
Instead of executing the ASPX page, the CLR actually executes the code
in the compiled DLL file corresponding to the ASPX page. The compiled
DLL file is placed by ASP.NET into a special directory structure
within the Temporary ASP.NET Files directory. The MSIL (DLL) file is
then loaded into memory and methods in the file are invoked. As each
method is invoked the CLR just-in-time compiles the method from MSIL
into native machine code.
If user 1 requests a .aspx page (HomePage.aspx), and invokes one of
the methods in that page (HelloWorld()), I understand that the .aspx
to .cs conversion will occur, and the .cs file will be compiled into a
DLL, and the DLL will be loaded into memory, and the HelloWorld()
method will be JITed into native machine code, and cached in memory,
so subsequent requests to the method will run more quickly.
Question 1. Let's say user 2, from a new browser, now requests the
same page and activates the same method. What benefit is there to
user 2? The conversion step from .aspx to .cs has already been
performed. And the compile from the .cs file to MSIL DLL step has
been performed. But what about the Just In Time compile of the
method? Does this have to be done again for user 2, since he is
running in a separate process space? Or is the Native code persisted
somewhere on disk or available somewhere in memory, such that user 2
can skip the JIT step also?
Question 2. Ngen.exe is used to pre-JIT a MSIL DLL file into a (?
extension) native machine file. But does Ngen.exe have anything to do
with the .aspx to .cs conversion step or the .cs to MSIL DLL step? Or
can I only Ngen the code behind file?
Question 3. Jeffrey Richter in his article at
"http://www.codeguru.com/Csharp/.NET/net_general/toolsand3rdparty/article.php/c4651/"
says "assemblies can be loaded in a domain-neutral or
non-domain-neutral fashion. NGen.exe produces code that assumes that
the only assembly loaded in a domain-neutral fashion is MSCorLib.dll
(which contains the definition for Object, Int32, String, and more).
If, at runtime, it is the case that other assemblies are loaded in a
domain neutral fashion, the CLR cannot use code produced by NGen.exe
and will resort to JIT compilation. For ASP.NET applications (Web
Forms and XML Web services), ***strongly-named*** assemblies are
always loaded in a domain-neutral fashion and therefore they gain no
performance benefit from having a corresponding NGen'd file."
Is this saying that ngen is useless for basically **ALL** ASP.NET
applications?
Question 4. Is there any utility or automated way to automatically
perform the .aspx to .cs conversion and the .cs to MSIL DLL step?