Execute ASP code from ASP.NET: my weird idea results

Last week I wrote about my simple weird idea on executing ASP in an environment built with a VB COM object that execute a asp file through an Asp.net HttpHandler.

I added the necessary basic features to execute the old-classic DNA sample application: FMStocks 2000 SP2.

The asp extension is mapped on then aspnet_isapi.dll, a simple entry on my web.config, a simple HttpHandler receives all requests for asp files, passing Form, QueryString, ServerVariables, Session and Cookies collections and, after the execution of ASP code, reading some of them modified by ASP execution.

Most of the problems I have encountered were in parsing ASP code adapting it to the new execution environment: some words such as Clear, End and Write are reserved words in VB6.

I found that executing ASP code through my code is only about 5-10% slower than in normal ASP mode, but the "Average time to last byte" was about 200% slower, due the simulated environment.

I have demonstrated myself that executing and sharing state (Session and Cookies) between ASP and ASP.NET is possible, however my solution is not ready for a production site. I did not developed all possible ASP objects nor tested the solution with a lot of ASP applications.

But I am satisfied of the work done.

Depending of the feedback I would like share the code..


  • This is great news! I've been working on a large intranet with 5000+ ASP pages that is slowly being migrated to ASP.NET using frames and database session storage, and it's been a huge pain in the neck. This would be a really clean solution.

  • I was thinking I am the only one with these kind of problems.. ;-)

    I would do some documentation to share decisions made and discuss future enhancements.

  • Interesting. I like what you've done with output buffering. It removes the main bottleneck by keeping it unmanaged until the very end of the page treatment. You have a few side-effects, of course (redirect being one, but I suppose turning buffering on or off must not work either), but you could probably work around this by just turning back to managed code in these exceptional circumstances. I mean, Redirect could very well be a call to the managed Redirect, like in my code, and Response.Flush could send the existing buffer to the managed response and flush... So the correct approach is probably a mix of your code and mine.

    What did you think of the idea to call classic ASP code à la Web Service, with a proxy class?

    Yeah, let's share ideas and code. As far as I'm concerned, I have very limited development time to spend on this, but you can use what you want from my code if you find interesting stuff in there. And I have time for discussion. And if I can assist in any other way...

  • Yes, probably the right approach is a mix of the two ways.. I admit I prefer a pure managed approach, like yours..

    What do you mean with the proxy class? A web service to off-load execution of the asp code?

    Regarding sharing, seems we are in three interested in this weird idea.. ;-)

  • Read my paper. It's at the end. It's a proxy class that looks like those we use for web-services, except that it doesn't execute a web service but a classic-ASP function, from managed code. Very useful in a migration scenario where you have a lot of legacy non-UI code written in classic ASP classes.

  • Hi Marco,

    Your “proof of concept” is interesting. When I was working on CassiniEx, I wanted to see if I could get it to host Classic ASP applications as well. I tried doing it a little differently by actually loading the ASP ISAPI dll. However, it is so tightly integrated with IIS and COM+ that I abandoned that idea.

    Although your current code will work for basic ASP pages, there is one area it doesn’t handle. The problem is that it won’t handle components hosted in COM+. A lot of complex ASP applications will rely on components that are running in COM+. These components need access to the COM+ ContextObject. That’s a lot harder than running some VBScript in the scripting host. That’s the main reason I gave up on running ASP pages.

    For a lot of people, your code will meet their needs.


  • Kiliman: this is a very good point, but I don't think exposing the context to COM+ hosted components is impossible. For example, if you relay the Server.CreateObject method to the managed part, you should probably get the ASP.NET context. Of course, this would hurt performance. But perhaps it is possible to set the context object another way. I could speak to some COM+ people here.

  • hi..
    how to run pure asp coding in asp.net

  • Is Migration Required ??,
    why we go for to Develop Communication btn

    ASP and ASP.NET....

  • the links are not working at all...


  • yzShwc Very neat blog article.Much thanks again. Much obliged.

  • Im obliged for the blog post.Really looking forward to read more. Fantastic.

  • I value the blog post.Thanks Again.

  • Im grateful for the blog.

  • Fantastic blog article.Thanks Again.

  • Hey, thanks for the blog post.Really looking forward to read more. Really Cool.

  • Hey, thanks for the blog article.Much thanks again. Want more.

  • This is the right blog for anybody who needs to find out about this topic. You realize a lot its nearly onerous to argue with you (not that I truly would need…HaHa). You undoubtedly put a new spin on a topic thats been written about for years. Great stuff, just great!

  • May I just say what a relief to find a person
    that really understands what they're discussing on the web. You certainly understand how to bring an issue to light and make it important. More people should read this and understand this side of the story. I was surprised that you are not more popular given that you definitely possess the gift.

  • I believe that is one of the so much important information for me.
    And i'm happy reading your article. However want to observation on some general things, The web site style is perfect, the articles is truly nice : D. Just right job, cheers

Comments have been disabled for this content.