1 dll per page:
it is correct. the confusion most people have, is they look at the
source folders. a web site does not run from there. asp.net copies the
folder to tempormay folders, then compiles it. how much compiling is
required depends whether the site was precomplied. even a precomplied
site needs to be jit'd.
in a web application the code behind files are compiled into one
assembly placed in the bin folder by visual studio via the proper
language compiler. but the asp pages still need to be compiled into
partial classes. for this visual studio uses the aspnet_compiler for
final compilation.
this gives visual studio few options, as it has to follow the
apnet_compiler rules: where code is located, where dll are located, what
assemblies are produced.
the .aspx, .acx and .master files are compiled into assemblies with
hashed names. actually depending on compiler options some batching (just
like in 1.1) can occur where several aspx pages are compiled into one
assembly. a small site can have all pages compiled into one assembly and
user controls into another, but you can not count on this.
the batching behavior is what leads to reference bugs which are only
seen in production. if two pages reference each other and end up in the
same batch, the compiler is happy, but if they end up in different
batches then a compile error occurs.
currently web application are kind of hacky, because visual studio has
to hide the code behind files from the aspnet_compiler or they would be
included twice. it does this by creating yet another temporary folder
system to do compiles in. this is because unlike other compilers which
you can give a list of files to compile and their references, the
aspnet_complier compiles a folder.
so in general, a web application will produce more final assemblies then
a web site.
also a web application will take a little more disk space. this is
because at runtime, a folder is created for each page and all referenced
dll's are copied to the folder. the web application codebehind dll will
be duplicated in each assembly folder.
the asp.net compilation model is very complex due to its goals of
allowing page recompiles without recycling. it complicated due to the
fact that .net does not allow unloading of assemblies, except via domain
unload (recycle in asp.net). this means to recompiel a page, a new dll
must be created with a new name, then loaded into memory. you don;t want
these dll's to be too large, because the virtual memory is not given up
until the recycle.
for example, on a 32bit machine if the page assembly was over a gig,
then a recompile of the page would automatically cause a recycle,
because the load of the new page would cause an out of memory error
(only 2gb of memeory is avaiable in user space). this is extreme, but
assembly memory usage is competing with in-proc session memory.
-- bruce (sqlwork.com)
Mark Rae [MVP] wrote:
"Rory Becker" <Ro********@new sgroup.nospamwr ote in message
news:b0******** *************** ***@msnews.micr osoft.com...
>>also just like 1.1 a assembly is created per page
erm .. unless I'm missing something serious..... that's just wrong..
It is wrong.
>My understanding is that this is now true for a "web site" in ASP.Net
2.0 but was not true for ASP.Net 1.1 and is not true for ASP.Net "Web
Applications "
That is correct.
>"Web applications" and "Web Sites" are 2 different project types in VS
2005.
Correct.
>I thought that Web Applications followed the Old rules(1 Dll per
project) and that the Web Sites followed the alternative view of 1 dll
per page.
This was originally the only web project type in VS2005 and Web
Applications were then added back by popular demand via a ctp (or
something like that) and then later made more concrete via SP1.
Right again.
>Did I miss somthing?
Not really, though Web Deployment Projects add some extra options...
