Classic ASP to ASP.Net one-off session data copy

Question

We have an extensive classic ASP site, and we're looking to upgrade to ASP .Net (most probably the latest version). Obviously upgrading all the pages at once would be a leviathan task, so we're only looking to write new pages (and page rewrites) in ASP .Net at first.

There are two obstacles to doing so:

1. I have no idea how to access classic ASP session data in ASP .Net. This would only have to be set up once, as it is never modified by any page other than the login page. I'd prefer to have to make minimal changes to the classic ASP login page, but that's only a small preference.

2. The ASP and ASP .Net sessions would have to timeout at the same time, to keep the version difference seamless.

Could anyone offer any help, please?

Thanks in advance.

Answer 1

There might be a better way of doing this using newer IIS settings (must admit I've not kept up to date on what new goodies IIS7 can do). But you could do a XMLRequest from your ASP login page to a ASP.Net page. You could either pass through the settings you need in the Post data or have the .net page populate the session data itself if the logic is simple enough. The .net page would then return you a .net session id in the cookie, you need to set this in the ASP users cookie collection so that that user has both a .net and Classic ASP session cookie.

That would do it.

Answer 2

We faced the same task (not fun). Since Asp.Net session and Asp session can't be shared, we used a combination of methods, each appropriate to the situation.

• In some cases, we used cookies instead of session.
• In others, we set up automatically posting forms so that if a user's session information was set in a classic ASP page, after the session info was set, we redirected to an Asp.Net page that read in query string parameters and used those to set the same session variables for Asp.Net. Then once the Asp.Net page set the same variables, that page did a redirect to whatever page the original login page previously pointed to. The same worked in reverse.

So, in the second scenario, an example flow would have changed from:

User tries to access some protected content page -> redirected to login page -> logs in -> session info set based on login success -> redirected back to content page.

to

User tries to access some protected content page -> redirected to login page -> logs in -> session info set based on login success -> redirected to a .net page, passing along login credentials, etc. -> aspx page sets session info and then immediately redirects back to content page.

We knew it was a hack, but it worked in the short-term until we could get the sites all converted.