Share login and other state between ASP.NET and classic ASP – level 300
Sharing a login (some call it single sign-on) between ASP.NET and
classic ASP takes quite a bit of thought. Even if you have a
single web application with 1 .asp and 1 .aspx, the two are running in
completely separate memory spaces. You can’t share Session, or
any other piece of information. Only shared resources can be
accessed by both. Shared resources could include:
- File sytem
- Database
- Registry
- Available services (Web services, COM, queues, etc).
That last bullet point is what you want to concentrate on. Using
the file system or database to act as a Session object substitute is
not something I would recommend even if it would technically
work. I would recommend against the registry as well since it’s
just a specialized database.
Web services would allow you to expose anything inside the ASPX memory
space, but web services are currently the slowest way to communicate
between processes, so consider the pros and cons before deciding to use
them.
COM+ components are services in themselves, and communications with
them are fast, so they provide a unique way to communicate between
applications without sacrificing performance. I’d recommend
porting ASP to ASP.NET, but for a time, it might be necessary to make
the two work together.
Using COM or COM+, you can share .Net libraries with your ASP
applications, and if you have your .Net library run as a COM+
application on it’s own, it could hold application state that could be
shared between the ASP and ASP.NET. If you use this approach, try
to minimize the amount of shared state and only use it as a temporary
means while you convert your ASP application to ASPX.
Hint: Regasm.exe is a tool for exposing your .Net libraries as COM.
What about some sort of gateway/redirection page that would translate asp session to post/get variables to asp.net and back again? Obviously you wouldn’t want to do that if you’re moving between the pages on a frequent basis, but if you have two portions of a website/app that do more intra- than inter-technology communication then that ought to work, right?
Oskar,
Yes, that would technically work for a 1-time transfer of information. There are plenty of things that would technically work, but many aren’t reasonable. For instance, with your method, all information would be exposed over Http in clear text if you weren’t operating over SSL. Second, it would turn every one of these requests into two HttpRequests because of the intermediate translating page. In that case, it would be better to use ASMX because of the flexibility, and it would be just as slow.
There are plenty of things that will work, but your solution should be picked based on the needs of the application. I prefer not to slow down the application if there is an easy way not to, but then again, some applications don’t need to be fast (if they only have a handful of users).
True enough – but it WOULD have the benefit of not having to rewrite any of the legacy code, except any page that might now “talk to” a new ASP.NET page rather than an old ASP page.
How much (legacy) code would you need to change to implement a COM/COM+ solution?
Oskar,
You would just need enough code to instantiate and call a method on the COM component.