Question

I will be adding new pages and adding functionality to current pages.
I would basically like to use new technology and but I don’t know how should I add it to classic ASP pages

In other words, can I <#--include--> an aspx page in Classic asp page? Or anything of that sort, may be creating a user control in ASP.NET and using it in classic ASP?

Answer 1

You shouldn’t really add it to the existing classic ASP pages. You may want to perform a full (yet slow) migration from classic ASP to .Net. Otherwise, you may just simply want to add your new functionality in new pages completely. If you have a templated site, this may become a litle cumbersome because you will need to recreate those templates in .Net since mixing .Net and classic in the same file is not possible.

You could ultimately end up resorting to iframes, but this makes browsers goofy sometimes. If your application is dependent on session, you’ll need to account for that because .Net can’t access a classic session unless you stick to primitives (string/int/etc) and use an outside state provider (like SQL) to hold the data with a sessionid that can be passed.

Having a hybrid site is a very tricky prospect and not one to be taken lightly. Tread carefully or you’ll really put yourself in a pickle.

EDIT: Partial Hybrid example description

We had a 700 or so page site to transfer from classic asp to Asp.Net 2.0. Many of the pages were allotted time to be completely transferred during a single project, but a few areas were unable to be refactored and had to be accommodated. We put together a master page architecture for the new .Net structure, data library and business objects library, and we began the transfer. In incorporating the classic asp pages, we determined we had a few needs.

1. Since master pages would control basic layout, menu, header, footer, we would need to remove these elements from any pages brought over.
2. New session requirements were incompatible with existing session capabilities.
3. Classic asp pages must still be required to obey .Net formsauthentication.

I solved these problems with the following solutions:

1. Our application is targeted at a specific customer, so we were able to determine browser requirements. This allowed us to employ an iframe to hold classic asp content/applications without worrying that the iframe would go crazy on us in Webkit or Firefox or whatever.
2. To accommodate the session requirements, we built a small encryption/decryption engine in .Net and in classic asp that enabled us to encrypt a “query string” to pass the session information back and forth. It wasn’t super secure, just enough that the casual user would not be tempted to mess with data. In addition we had to build two translation files. The first translation file was a .Net library static method that would take the session data, extract the necessary pieces and create the query string. The second one was the classic asp version that was designed to read the query string, parse the data and create the session primitives directly.
3. Making the classic asp pages behave for .Net was a server management issue. To do this, using the formsauthentication attribute protection=”All” is supposed to be sufficient, but I found it still did not cover items that had other handlers anticipated. So I added a wildcard mapping in IIS to handle all files. From the properties of the IIS website, choose “Home Directory” and click “Configuration”. At the bottom of the next window is a “Wildcard application maps” box. Click insert and navigate to the version of .Net you use to find the aspnet_isapi.dll file. This will force all files to parse against this file (which is harmless except that it kicks up the authentication request).

I can’t provide specific code samples because of NDA, but this should at least provide some ideas on where to go from here.