ASP and ASP.NET

I'm currently working on branching an asp project, hopefully not for long. It took me some time to adapt myself back to its programming style, but I'm longing to go back to .NET.
This post is not about how to convince the stockholders than migrating a project saves money in the long run and allows branching a lot easier. It's not about how adding branches to old hard to maintain code increases costs, it might give money right away when you sell that branch in a direct proportion, but increases maintainability costs in an exponential way. I don't know how long it would take for you, humble programmer, to explain the difference between exponential and direct proportion.

As usual, I would like to summarize why I moved away from ASP 6 years ago, and why I look forward to move away from it today, the farther the better.

1. Classic ASP is hard to debug and maintain. Probably because of its own programming model. The mixture of asp code with HTML in a single .ASP page, the lack of a well defined object oriented hierarchy et-cetera.
2. Everything is interpreted script, in order to increase performance the best bet is to move part of the logic or functionality to COM components.
3. COM components require the components to be registered on the server, what brings into account the well known DLL hell and adds deployment complexity. It also makes debugging more complex, you cannot debug locally unless you have the COM components registered on your machine. You have to have exact versions of the COM components in the development and production environments. This rules out shared web hosting.
   
4. VBScript is not strong typed. Syntax errors are discovered most of the time when the call to your script shows a 500 http error. There is no way to discover any error at compilation time, because there is no compilation time :-p.
5. In order to debug your script, you're better off writing response.writes to the screen or taking guerrilla techniques.
   Definition of Guerrilla Technique: Select the whole content of your script, cut it and paste it in an open notepad windows. Type in a Response.Write ("I'm Here. I made it into MyScript.asp") and request the page after saving it in your IIS box. Then start copying and pasting small chunks of the original code at a time till you no longer see the "I'm Here..." So you can determine the failing line of code.
6. Classic ASP is not event driven programming, if you want event driven response, you better get a JavaScript book or bookmark a good online reference. It's true that you should know JavaScript no matter what, some .NET programmers abuse the numbers of trips to the server that could be saved with some client side logic.
7. In order to have a nice grid that you can re-use in your daily reports you have to write humongous amounts of code, even more if the grid has pagination or sorting capabilities.
8. Option Explicit is off by default in classic ASP, oh no! (Note: it becomes Off by default since VS 2003 if I remember correct)
   

I'm sure some people will point out some advantages. I can hardly think of two of them:

1. When you set the form action attribute in html to a certain script, it certainly requests that script on the server, it doesn't go to the same original page that contents the form. Ok, ok, without removing the feature, it wouldn't be possible a Page.IsPostback property in .NET. Have you ever tried that in .NET? I mean setting the action attribute, not the Page.IsPostback, dummy.
   
2. Some coworkers have said the OnError type of error treatment is better than the Try Catch because it lets you Resume Next. To be honest, I'm quite fond to do proper Exception Handling so no thanks.