ASP .NET 2.0 Unanswered questions...

  • Thread starter Thread starter Scott M.
  • Start date Start date
S

Scott M.

I've asked this before, but not gotten any clear answers, so I'd figure I'd
try again.

I am an experienced ASP .NET 1.1 developer and I understand the differences
between an ASP .NET 2.0 "Web Site" vs an ASP .NET 2.0 "Web Application"
(among other things, all compiled code placed in several assembly files vs.
one assembly file).

Here are my 2 questions:

ASP .NET 2.0 "Web Application Project"
=============================
In ASP .NET 1.1, when you use a DataAdapter (say with the DataAdapter
Configuration Wizard), you'd be able to see all the wizard's generated code
in the code-behind and perhaps tweak it. In ASP .NET 2.0 Web Application
Project, if I use a TableAdapter and configure it using the designer, I
can't find any code (yes, I know to look in the designer.vb file, rather
than the code-behind) for it.

Where is the code that makes all this new cool ASP .NET stuff work with some
configuration? I know I can't just see the underlying code for the class,
but I want to see the code for the instance. Where is it?!

ASP .NET 2.0 "Web Site"
==================
Where are the compiled assembly files placed? I don't see them anywhere in
my site's directory structure.


No offense, but please only respond if you *know* the answers, not if you
just have suggestions on where I *could* look.

Thanks,

Scott
 
I will attempt to answer your questions here without upsetting you too much
as I'm pretty sure I "know" the answers to your questions:

1, Where's the data adapter code?

In 2.0, in the web application project, XSD designers including data
adapters are considered partial classes. They are also compiled and the code
is generated for them at run-time. Therefore, there is no code to view. If
you want to override a method or property, add attributes, directives or
change the way those adapters work or map outside of the designer, simply
create a new code file in your App_Code directory and define a class (in
your dataset adapters namespace) called the exact same name as the data
adapter and mark it as partial (e.g. public partial class
MyDataTableAdapter), no need for inheritence, this will already be set up
for you, you can however add interfaces if you wish. Then you will notice
when typing "override", you are provided with the virtual methods and
properties from your data adapter and can manipulate the class without
having to "inherit" from it.

2, Where have all the assemblies gone?

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\%app
name%\
and then followed by intertwined assembly directories and cache created by
the runtime, e.g. agentonline\88ab2d2c\588ae2f5\ and then you will find your
assemblies such as App_Browsers.dll, App_Code.dll, App_Web_wu_bfbz-.dll,
etc.

Hope this helps you out.

Regards,
Chad
 
It seems to me that by having to generate the code for, say a TableAdapter
at runtime, the application execution would be slowed. Do you mean that
this code is generated at build time and then added to the assembly?

Thanks Chad!
 
Yes, that's what I meant. Sorry.


Scott M. said:
It seems to me that by having to generate the code for, say a TableAdapter
at runtime, the application execution would be slowed. Do you mean that
this code is generated at build time and then added to the assembly?

Thanks Chad!
Click to expand...
 
question 1:

the fundamental change with .net 2.0 was implementation of partial
classes. this changed the way designers worked.

in 1.1 they generated code il code that was then converted to the
language of choice, so that the source could be edited (sometimes by the
designer only) if needed.

in 2.0 the designer just produces il code, because it can be merged with
a language source file to produce one class. there are no hidden source
files, because they are not created anymore. this is way you can not
find the tableadapter code.

the only way to see the designer source code is to find the assembly it
ended up in (easier if in the app_code folder or seperate project, as
only one assembly is created) and recompile it (or use reflector).



question 2:

..net 2.0 (just like 1.0) creates temp folders that the web site is
copied to and compiled. where these folders are depends on configuration
but the default is under the .net installation folder.

just like 1.1 the folder are really a hashed set, with a folder for each
assembly and rev (say a recompiel of one page).

also just like 1.1 a assembly is created per page (for both web sites
and web applications), so finding the folder for the desired page is a
little work.

you can precompile the site to a work folder with the aspnet_compiler,
and its easier to find stuff, because all assemblies are in the bin folder.

-- bruce (sqlwork.com)
 
One other point worth mentioning Scott. There are two different ways
of deploying an ASP.NET 2.0 web site - copying and "publish"

There is a tool for copying the web site in VS2005 which is a very
convenient way to deploy if you want to do incremental updates. It
does mean that no DLL assemblies are uploaded but caching on the web
server should compensate on a reasonably busy site where the traffic
is not spread among too many different pages.

The publish option does create a deployed site in a manner very
similar to the "release" version of ASP.NET 1.1 (i.e. a bin directory)
but according to Microsoft this method is not necessary unless it is a
very large site where traffic is spread over a lot if different pages.

HTH
 
also just like 1.1 a assembly is created per pageerm .. unless I'm missing something serious..... thats just 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"

"Web applications" and "Web Sites" are 2 different project types in VS 2005.
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.

Did I miss somthing?
 
Hi Bruce,

Thanks for the explanations. I have a couple of comments questions,
inline....

question 2:

.net 2.0 (just like 1.0) creates temp folders that the web site is copied
to and compiled. where these folders are depends on configuration but the
default is under the .net installation folder.
Click to expand...

Yes, but in 1.1 the initial IL assembly was placed in the /bin folder of the
ASP .NET project directory. ASP .NET Web Sites don't seem to have this?
That is what I was inquiring about.
also just like 1.1 a assembly is created per page (for both web sites and
web applications), so finding the folder for the desired page is a little
work.
Click to expand...

??? In 1.1 there was not one assembly per page. There was one assembly per
project. You could have 1000 pages and just one assembly.
you can precompile the site to a work folder with the aspnet_compiler, and
its easier to find stuff, because all assemblies are in the bin folder.
Click to expand...

Is that NGen or someting else that pre-comiles it?

Thanks Bruce!
 
erm .. unless I'm missing something serious..... that's just wrong..
Click to expand...

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"
Click to expand...

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.
Click to expand...

Right again.
Did I miss somthing?
Click to expand...

Not really, though Web Deployment Projects add some extra options...
 
Did I miss somthing?
Not really, though Web Deployment Projects add some extra options...
Click to expand...


Cheers man. For a moment there, I thought I'd slipped into a parallell world
or something.
It's been the type of week where that might have explained a lot of things :)
 
Thanks Phil.


Phil H said:
One other point worth mentioning Scott. There are two different ways
of deploying an ASP.NET 2.0 web site - copying and "publish"

There is a tool for copying the web site in VS2005 which is a very
convenient way to deploy if you want to do incremental updates. It
does mean that no DLL assemblies are uploaded but caching on the web
server should compensate on a reasonably busy site where the traffic
is not spread among too many different pages.

The publish option does create a deployed site in a manner very
similar to the "release" version of ASP.NET 1.1 (i.e. a bin directory)
but according to Microsoft this method is not necessary unless it is a
very large site where traffic is spread over a lot if different pages.

HTH
Click to expand...
 
I hope all of you got this right by now before (e-mail address removed) comes
back in.

keep on going if you have some more true facts to add and 100% sure of your
answers.

Thanks by the way.
 
IfThenElse said:
I hope all of you got this right by now before (e-mail address removed) comes
back in.

keep on going if you have some more true facts to add and 100% sure of
your answers.
Click to expand...

?????
 
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)
 
1 dll per page:
Click to expand...

1 DLL per web application.
it is correct.
Click to expand...

No it isn't.
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.
Click to expand...

Indeed - one DLL.
but the asp pages still need to be compiled into partial classes.
Click to expand...

That's correct, but irrelevant to the number of DLLs created.
for this visual studio uses the aspnet_compiler for final compilation.
Click to expand...

Again correct, but again irrelevant - a web application will compile into
one assembly.
so in general, a web application will produce more final assemblies then a
web site.
Click to expand...

Incorrect.
 
Bruce....

....can you point to any references to back this up?

Whilst I am interested in all versions of ASP.Net, I would be very interested
for you to provide a reference which suggests that an ASP.Net 1.1 application
produces 1 assembly per page as I do not believe this is the case.

Likewise I have not seen this behaviour for ASP.Net 2.0 "Web Applications"

All shadow copied assemblies appear to be literally copies of those found
in a Bin directory of the Web Applications source.

Also I believe that with the exception of NGen (whose native images are ignored
by ASP.Net 1.1 anyway.) Jit compiling does not produce further assemblies
as it is an in-memory process only.

Thanks
 
Whilst I am interested in all versions of ASP.Net, I would be very
interested for you to provide a reference which suggests that an ASP.Net
1.1 application produces 1 assembly per page as I do not believe this is
the case.
Click to expand...

It isn't...
Likewise I have not seen this behaviour for ASP.Net 2.0 "Web Applications"
Click to expand...

Of course you haven't...
 
My previous reply to Bruce regarding his interesting claims was merely the
politest version of the original text i came up with.

I hasten to add that at no point did I think of writing anything which I
would have wanted to cause upset.
we're talking things like....

-----------------------------
Bruce man you're smoking some good shit.
-----------------------------
...Or..
-----------------------------
I call Bullshit
-----------------------------

The thing is they just seemed a bit antagonistic.

However I would like to thank Bruce and yourself because I had not discovered
any of the Web Deployment Project /ASPNet_Compiler references before they
were mentioned by yourselves.

So all in all it's been very interesting so far....

I am still interested to hear bruces take on things.....

It's amazing how language barriers etc can lead to misunderstandings of various
kinds.

Perhaps Bruce does not mean what he appears to be saying. :)
 
Back
Top