Advantages of ASP.NET vs. ASP 1

[RottPaws]

I've been building ASP pages for a little over a year now and I've done some reasonably complex applications.

I've seen a number of threads on this forum asking about tutorials and such for ASP.NET. I've looked at some of them, but I haven't found anything yet that makes me want to go out of my way to make the jump.

What are some examples of useful or even just nifty things that can be done with ASP.NET but either can not be done or are particularly more difficult to do with "classic" ASP?

_________
Rott Paws

...It's not a bug. It's an undocumented feature!!!

 

[link9]

Besides the fact that ASP.NET is now fully object oriented (which should be enough in and of itself w/ absolutely no other advantages whatsoever), here are some other threads where this topic has come up.


thread855-265989 faq855-3257 thread855-479720

The links in my initial thread no longer work, and I can't put my hands on the sample project I had worked up way back when, but here is the text of the text file, which I was able to find. Hope you see the light lest you find yourself in the back of the bus w/ the Fortran & Cobol programmers.

-----------------------------------------------------~~~

-----good training--------

developmentor.com
develop.com

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

random notes (most have examples in 'test' web app):

use stringbuilder class for string concatenation

use web.config to store connection information

use dataview to bind to a datagrid -- adds sort capabilities (can't sort a dataset intrinsicly)

datagrid sorting still does not have built in 'autoreverse' sorting capabilities, but it's easy
enough to add it yourself as an addition to the default sorting capabilities. And
better yet, you could write your own datagrid custom control, inherit the existing one,
and simply add the functionality through a programmatically set property.

user controls have their own page_load event and can also be cached...
caching user controls & then dropping them onto a page enables partial page caching
where other parts of the page are dynamic, the individual cached user controls are not

sending mail now requires two object... the first is a mailMessage object, which is
used to construct the message. You then encapsulate that object in an smtpMail object
which has an smtpHost property and a send method to actually send the mail

independent assemblies can (and probably should) be written and compiled under a different project
than the one that you're working on. Under the properties window of your project,
kill the 'root namespace' option so that you can setup your own namespace hierarchy.
From that point, in any project where you want to use the assembly, go under the
'references' node of your project, and add the .dll to the list. Then, on any page
where you want to use it, first use the Imports keyword at the top of the page to
import the namespace and then you have free access to an instance of the object.

You can now go into machine.config, search for 'forbidden' and find a node in that file that lists
specific file extensions that the web server will not serve up directly to a user.
.config is already there. .vb is already there.
You can add .inc to protect that particular extension as well... along with any others.
This is a great addition to the security of .asp. YOu can find this file in the installation
directory for Microsoft.NET

User controls and Custom Web Controls are the wave of the future. This is the best way to get your
development time down and provide a great way to re-use your code... break your apps into little
re-useable pieces and spend the time to write them.

The notion of caching is widely held to be the single best way to improve performance. Whether it's full page output caching or partial page output caching (via user control caching), the best
way to improve performance is to cache.

When testing pages, you must first 'build' the project, which will make the project class, which
is then used to serve your application. If you try to just save & go, you will
receive an error stating that the engine could not load your class.

The above step is the initial compilation there is still one more compilation to go before the
page is actually ready to go, and that's the JIT (just in time) compilation which occurs
the first time your page is requested. Due to this fact, the first time a page is requested,
there is a delay in response time. This is when the compilation is happening. The resulting
class that is compiled then is actually the version of the page which is served to any
and all subsequent requests (resulting in blazing performance) until the web service is
restarted, at which time another JIT compilation will have to occur.

This is somewhat annoying at times, and to avoid your users from having to encounter this first
time slow response, you can use the 'application test center' to go through and hit
all your pages at least once before you go into production (or after any service restart)
so that none of your users have to sit and wait for that to happen. Hopefully, MS will
provide something a little better than that (possibly an option that you can check) in
future releases of ASP.NET.

Page tracing can be a useful utility (one step below debugging) -- it can output many variables
about page execution and application state that, in ASP classic, would have taken multiple
response.write()s to output... such as all request.serverVariables() and such... cookie state, etc.

Session state has been vastly improved in .NET. Instead of being held in process, session variables can
be set to be held out of process, and in web farms, even on a completely different machine.
This does improve on some of the pitfalls from asp classic's session object, but it
should still be kept in mind that the variables are still held in memory somewhere, and this
can negatively affect performance on high traffic sites. Use at your discretion.

IIS and ASP.NET are now hosted in separate processes, as well (asp classic hosted in same process). This
means that if your application hangs or crashes (which is much less likely to happen now
than before), and the ASP.NET engine needs to restart, this will not affect your webserver.
This restart will take around 5-10 seconds, and during that time, any .aspx pages will
still have to wait, any other type of page will still be served, as IIS is not affected
by an ASP.NET crash. It is important also to note that the requests for .aspx pages are
actually put into queue, rather than being served a 404 or 500.1 error, which is pretty graceful
considering a crash just occured. They simply wait for the process to come back online,
and then they are served.

Garbage collector detects and recovers automatically from problems, such as memory leaks, deadlocks, and
access violations. Still a good idea to clean up after yourself, but it's not so imperative
as it was in asp classic. Now, you'll see a decrease in performance if you don't, whereas
you could have crashed in the past.

The answer to getting answered -- faq855-2992