what is the better approach in sharing session of asp classic and asp.net?

I have an asp classic and asp.net application. I want to share the session from asp classic to asp.net back and forth. I made a solution to share the session by iterating the session names and put it in the hidden objects. This works fine , but I don't know if it is a better approach to share the session. iread some articles some of them using xml and pass it through form posting, some using cookies, and the other are using database.From this approach, what is the best to impleemnt with, or is ther开发者_高级运维e any other best solution?

---

Unfortunately your description of what you've already done is not very clear:

I made a solution to share the session by iterating the session names and put it in the hidden objects.

So, I'm going to go back one step and approach it from there. Before that, however, I should say that I don't think integrating two systems on this level is a good idea at all; you are trying to make two systems work together by replacing some of the piping that they run on, in such a way that they don't really notice. This might open you up for errors later on, when something changes and the relevant change is not made in the other system. I also would advise against the heavy use of sessions in general, although many ASP systems did abuse it.

Basically, both the classic ASP and ASP.Net's session works similarly, they use a session identifier (either stored automatically as a cookie - usually the default, or passed via the URL), and allow you to store key / value pairs of objects against this session identifier.

If you want to share the objects in session, you can either pass the information directly between the two applications when they interact (this would be the "form posting" approach), or store it in an external place, such as the database. I have some issues with the form posting approach, namely:

• It is passing data which should be strictly on the server to the browser and back again, which has both security and bandwidth implications (you would probably want to at least encrypt the data);
• It assumes that you have a clear handover or boundary between the two applications. This may or may not be the case.

I don't really see too many benefits to this approach, apart from the fact that it's probably the simplest, as long as you have limited interactions (say, a few fields, and only one or two pages that interact). The same argument goes for any other approach that passes all of the session info to the browser and back to the server (e.g. storing everything in cookies).

Other approaches will assume that you have a place to store your session, let's assume a database for now. With a database, we have a single place where the data exists, and each application can simply read and write to this single place. If you have a large number of different interactions, and / or the systems don't have a clear handover to each other, this is clearly an easier approach.

What remains is a question of how to encode the different types of data and how to store it. This is essentially a question of encoding, and you would need to be fairly clear on the different data types being used on each side (you should make sure that the ASP.Net code uses types that are at least logically equivalent to the ASP data types).

To go about implementing this, I would create a database implementation which supports how I want to store my session data. It could be a simple key / value pair table, along with data type information, or it could be more normalised than that, it's your decision. After this, I would create a new implementation of Session for each application, which makes use of this database. All that is left is to replace all references to the standard Session objects with the new Session that you've created, and everything should work. This is probably similar to what you've done, but I am specifically mentioning the use of a database as a data store.

Performance issues and the cleaning of old sessions should be relatively easy to work out, although this implementation will definitely be slower than an in-memory implementation.

---

I know its not exactly an answer to your question but I have worked on and integrated my self a few .net and classic asp applications, just wanted to give you some comments from my experience:

it can be confusing if its not well documented.. on some of the systems that were not properly documented when we re-deployed we missed out a .net app that handled part of the functionality

the most solid and best to work with (in my experience) were the ones where we picked one application to be the "core" with other parts making calls to this core to get work done.

for example creating .net applications (desktop, web, handheld) that called classic asp web pages that were effectively providing a simple xml web service - seeing as the classic asp apps tended to be the legacy "core" part of the system. (xml web services are fun to write in classic asp - seriously they are fast and easy to code - no type casting issues ;-) )

I don't know what you are doing here specifically but i found that this approach made the structure of the code more intuitive and actually simplified many odd associated issues beyond sessions e.g. on one app had an access DB used as part of it and only having classic asp access it removed concurrency issues.

May not be of any use but its based experience working with around 10 operational management systems that integrated .net and classic asp in various ways.