ASP .NET 2.0 Unanswered questions...

[Scott M.]

Bruce,

I'm sorry but you are just plain wrong on ASP .NET Web Applications (both
1.1 and 2.0). Regardless of how many pages you have, you will wind up with
just one physical assembly file per application. Yes, there is the initial
one (placed in the /bin folder) and then a compiled version of it placed in
the Temporary ASP.NET folder that IIS actually uses, but just one per
application.

-Scott

 

[bruce barker]

in both 1.1 and 2.0 there are two types of source files. code behind
usually written in c# or vb, and asp.net source files.

version 1.1 of asp.net in order to support inline server script (or
asp.net codebehind with no visual studio support), generated source code
for the page, then called the desired compiler to build a dll. this was
done on the first request to the page. the source file was produced in a
temp folder (and an actual compiler script), and after being built the
assembly was loaded into memory. this also required all dll's in the bin
folder be copied to the temp. a visual studio project would build the codebe

in version 2.0, because of partial classes, the aspnet_compiler converts
aspx pages to il directly, (actually so did 1.1, but it used the .net
codedom library to convert il to source code). version 2.0 has a bunch
of compiler options, (if you look in your msbuild scripts you can see
the aspnet_compiler options you are using). you shoudl read the
apnet_compiler documentation to get an idea of how it works.

you can also look in your deployment project. if the aspx pages are all
empty (no source) then your site was precompiled for all the aspx pages
and has been batched into dll's (again depending on compiler switches).
if they contain source code, then they will be compiled at runtime on
first page request much like 1.1

again in version 2.0 the only difference between web sites and web
application is the handling of the code behind files compilation
(whether the aspnet_compiler call the language compiler or msbuild) and
in the case of a web applications the existence of a project file. there
is no difference in how the aspx pages are compiled.

in either case you should use deployment projects to build a deployment
folder.

even if you use only notepad, and the aspnet_compiler, to build a
production web site, you can get the same results as visual studio.

again the main benefit of web applications (to the developer) is not
having to define formal interfaces in the app_code folder for pages to
call each other (this is what broke most 1.1 apps trying to move to 2.0
and drove MS to release web application projects).

i personally feel defining interfaces is a better practice (see
interface design pattern), but it is more work.

in any case disk space is cheap and you shouldn't worry too much about
how many dlls are produced.

ps. looking in vs2008, with a web application i can see no way with
visual studio to do a full precompile of the aspx pages like you can
with a website. you could still update the msbuild file manually to do
it though. i'll check with vs2005 when i get chance to see if it has the
same limitation.



-- bruce (sqlwork.com)

 

[Scott M.]

But Bruce, you seem to be talking about the compile process more than the
simple fact that in 1.1, only one assembly file is produced. It is
*possilbe* to deploy pages without the assemblies and let that process
happen on the fly. But, when producing assemblies ahead of time, there
would just be the one.

 

[Juan T. Llibre]

You're saying that VS 2003 produces a single assembly.
Bruce is saying that when VS 2003 isn't used, more than 1 assembly is produced.

I.o.w., using the same 1.1 .Net Framework version will produce either one assembly
in the bin dir...or no assembly, depending on whether you use VS 2003 or not.

Did you know that you can *also* pre-compile ASP.NET 1.1 applications ?
In effect, that prevents the "first-compile" lag when deploying 1.1 apps.

See :

http://www.daveranck.com/DesktopMod...wNYKdc5QG96uQVGIVKnqYDdV0c0Z3bI/K2zjiZf30S5o=

 

[Scott M.]

You're saying that VS 2003 produces a single assembly.
Bruce is saying that when VS 2003 isn't used, more than 1 assembly is
produced.

He has also said in this thread that VS 2003 produced multiple assemblies
(one for each page).

I.o.w., using the same 1.1 .Net Framework version will produce either one
assembly
in the bin dir...or no assembly, depending on whether you use VS 2003 or
not.
Yes.


Did you know that you can *also* pre-compile ASP.NET 1.1 applications ?
In effect, that prevents the "first-compile" lag when deploying 1.1 apps.
Yes.


See :

http://www.daveranck.com/DesktopMod...wNYKdc5QG96uQVGIVKnqYDdV0c0Z3bI/K2zjiZf30S5o=

 

[Juan T. Llibre]

re:
!> He has also said in this thread that VS 2003 produced
!> multiple assemblies (one for each page).

He was talking about a different kind of assembly: JIT-compiled assemblies.
Those go in the Temporary ASP.NET Files directory.

In essence, you were both right...but were talking about different things.
Sometimes, semantic problems are more complicated than programming problems.

<chuckle>

Btw, I appreciate/value your regular contributions here.

 

[Scott M.]

re:
!> He has also said in this thread that VS 2003 produced
!> multiple assemblies (one for each page).

He was talking about a different kind of assembly: JIT-compiled
assemblies.
Those go in the Temporary ASP.NET Files directory.

Yes, but he said that this assembly was created one per page, and they
aren't.

 

[Rory Becker]

re:

!> He has also said in this thread that VS 2003 produced
!> multiple assemblies (one for each page).
He was talking about a different kind of assembly: JIT-compiled
assemblies. Those go in the Temporary ASP.NET Files directory.

I still say these are not Jit Compiled. These are shadow copies. and there
is still only 1 per project not 1 per page.

If someone wants to find an official reference that contradicts this then
go for it, but I really don't think you'll find one.

 

[Juan T. Llibre]

re:
!> there is still only 1 per project not 1 per page

I suggest you examine your ASP.NET Temporary Files
directory for any ASP.NET 1.1 application you have running.

You'll find one assembly for every page, not one assembly per project, and they *are* JIT-compled.

I still say these are not Jit Compiled. These are shadow copies. and there is still only 1 per project not 1 per page.

 

[Juan T. Llibre]

re:
!> Yes, but he said that this assembly was created one per page, and they aren't.

They are.

Look in the ASP.NET Temporary Files directory
for any ASP.NET 1.1 app you have running...and verify that.

You'll also find an assembly for each component
in the "assembly" sundirectory of your app.

In fact, in my ASP.NET 1.1 discussion board subdirectory, there's 54 assemblies in
several subdirectories of the app's .Net Framework 1.1's ASP.NET Temporary Files directory.

That same application has 7 assemblies in the /bin subdirectory
( it uses six component dll's, over and above the compiled project's dll... )

 

[Rory Becker]

re:

!> Yes, but he said that this assembly was created one per page, and
they aren't.
They are.

Look in the ASP.NET Temporary Files directory
for any ASP.NET 1.1 app you have running...and verify that.
You'll also find an assembly for each component
in the "assembly" sundirectory of your app.
In fact, in my ASP.NET 1.1 discussion board subdirectory, there's 54
assemblies in several subdirectories of the app's .Net Framework 1.1's
ASP.NET Temporary Files directory.

That same application has 7 assemblies in the /bin subdirectory ( it
uses six component dll's, over and above the compiled project's dll...
)

I can find no evidence in any of my long running ASP.Net 1.1 applications,
of any assemblies that do not have an exact mapping either to a referenced
Assembly (Log4Net.dll for example) or to a project within the solution from
which the Application was built.

Again I ask for official documentation which refutes this.

Stating that you have some assemblies on your machine really doesn't help
your case.

I suggest again that the multiple assemblies found are instead the result
of much shadow copying.

 

[Scott M.]

re:
!> Yes, but he said that this assembly was created one per page, and they
aren't.

They are.

Look in the ASP.NET Temporary Files directory
for any ASP.NET 1.1 app you have running...and verify that.

When I look in the ASP.NET Temporary Files directory for 1.1 apps., I see
just one assembly (which is based on the one that exists in my /bin folder).
1.1 is not new to me. I've seen this one assembly behavior over and over
for many years now. If I have 100 or 1000 pages in my ASP.NET 1.1
application, there will just be one assembly produced in my /bin folder and,
as a result of compilation, there will just be one other assembly placed in
the ASP.NET temp folder.

As for finding other component assemblies in these folders, that may be
true, but those assemblies are not for the ASP.NET project's code itself,
they are for the references.

 

[Scott M.]

I still say these are not Jit Compiled. These are shadow copies. and there
is still only 1 per project not 1 per page.

That's where we disagree Rory. The assembly in the temp folder *is* the JIT
version of the project assembly.

http://www.codeproject.com/aspnet/PreCompileAspx.asp
I also found this (look at the temporary files section)
http://msdn2.microsoft.com/en-us/library/aa479328.aspx#aspnet_http_runtime_topic5

 

[Scott M.]

re:
!> there is still only 1 per project not 1 per page

I suggest you examine your ASP.NET Temporary Files
directory for any ASP.NET 1.1 application you have running.

I have Juan and, as expected and experienced for 5 years now, just one
assembly for the project exists in the /bin folder of the project and the
JIT version is in the temp folder.

 

[Juan T. Llibre]

re:
!> When I look in the ASP.NET Temporary Files directory for 1.1 apps., I see just one assembly

Evidently, your .Net Framework 1.1 works diffently than mine.
I'll have to go back and revise the ASP.NET books I've written if that's the case.

 

[Juan T. Llibre]

re:
!> Again I ask for official documentation which refutes this.

Why don't you present "official documentation" which supports it ?

re:
!> Stating that you have some assemblies on your machine really doesn't help your case.

Except that they're there...which must mean *something*.

 

[Rory Becker]

!> He has also said in this thread that VS 2003 produced

That's where we disagree Rory. The assembly in the temp folder *is*
the JIT version of the project assembly.

http://www.codeproject.com/aspnet/PreCompileAspx.asp
I also found this (look at the temporary files section)
http://msdn2.microsoft.com/en-us/library/aa479328.aspx#aspnet_http_run
time_topic5

Thanks Scott

Interestingly this 2nd article seems to suggest that Bruce is correct under
certain circumstances ......
---------------------------------------------
By design, the HttpApplication object looks for a class named after the requested
ASPX file. If the page is named sample.aspx, then the corresponding class
to load is named ASP.sample_aspx. The application object looks for such a
class in all of the assembly folders of the Web application—the Global Assembly
Cache (GAC), the Bin subfolder, and the Temporary ASP.NET Files folder.

If no such class is found, the HTTP infrastructure 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. The newly
created assembly has a randomly generated name and is located in an application-specific
subfolder of the following path: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET Files.
---------------------------------------------

I have yet to try this but it seems to apply when the ASPX represents a class
which is not in the project assembly. I have no idea what would cause that
though.

Interesting......

 

[Rory Becker]

re:

!> Again I ask for official documentation which refutes this.
Why don't you present "official documentation" which supports it ?

re:
!> Stating that you have some assemblies on your machine really
doesn't help your case.
Except that they're there...which must mean *something*.

Juan, I think Scott has pointed me at a page which might explain things.

See my reply to him for details.

However I suggest "again" that ""they're there on my machine" is sufficient
evidence for all those of us that can see your machine...
They are not there on my machine or on Scotts (apparently)

However as I said there appears now to be some indication of why.

Could you possibly chime in against my other rply and indicate how you have
created a 1.1 web app where you have aspx pages not represented by classes
in your main assemblies as I think it is this that is causing this side effect.

I have no such pages in my applications and I feel this is why Myself and
scott have missed this.

Thanks for your contributions (you too Bruce).

It's always nice to learn something new. It would just be nice now to know
under what circumstances this is useful

 

[Scott M.]

However as I said there appears now to be some indication of why.

Could you possibly chime in against my other rply and indicate how you
have created a 1.1 web app where you have aspx pages not represented by
classes in your main assemblies as I think it is this that is causing this
side effect.

I have no such pages in my applications and I feel this is why Myself and
scott have missed this.

This has been covered already though in this thread Rory. *If* you don't
compile your pages and just deploy them w/o an assembly, you will get an
assembly per page in the temp folder, but I have said (in at least 2 posts
in this thread) that this scenario is *not* what I am referring to, yet
Bruce has insisted that even when you do use a compiled assembly, you'll
still get one per page - which I don't think is correct.

-Scott

 

[Scott M.]

I guess so. I have lots of books that have incorrect information in them.