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.