ASPTypeLibrary.Session access from asp.net

[Nate]

All,

My department has recently been tasked with converting an ASP 3.0 web
application to an ASP.NET 2.0 web application. Currently, in order to read
values from the ASP 3.0 Session from an ASP.NET web page we have to use a
session bridging technique. There are several techniques out there to
workaround the incompatibility of the 2 session state storage mechanisms (3.0
vs .NET). The problem that I have with all of the techniques is the extra
time that elapses as we "call" the bridge from the ASP.NET page. The system
is already highly stressed with its abundance of users and I am looking for a
more elegant and faster solution.

What I would like to do is make a .NET library that will wrap the
ASPTypeLibrary.Session. The problem is that since the .NET library will be
invoked from a .NET web page, it won't have any ObjectContext in order to
initialize an object of type ASPTypeLibrary.Session. To further complicate
matters, there is no mechanism that I see that I can use in order to get a
reference to the "legacy" session. I can read out all of the possible values
that my library would need in order to "feed" the asp library in order to
fetch an existing instance of an ASP 3.0 session (i.e. ASPSESSID cookie,
virtual directory actual path, hostname, ip, relative path, etc, etc, etc).
My problem is that I can't find where I can "feed" all of this info to (or
parts thereof) in order to get what I want back out.

I realize that this may very well delve deeply into
behind-the-scenes-programming-voodoo, and I am fine with that. It will be
very well tested before we let it go out to our production web servers.

Any suggestions, links, etc... will be very much appreciated.

Thanks,
Nathan

 

[Evertjan.]

=?Utf-8?B?TmF0ZQ==?= wrote on 11 jan 2007 in
microsoft.public.inetserver.asp.general:

All,

My department has recently been tasked with converting an ASP 3.0 web
application to an ASP.NET 2.0 web application. Currently, in order to
read values from the ASP 3.0 Session from an ASP.NET web page we have
to use a session bridging technique. There are several techniques out
there to workaround the incompatibility of the 2 session state storage
mechanisms (3.0 vs .NET). The problem that I have with all of the
techniques is the extra time that elapses as we "call" the bridge from
the ASP.NET page. The system is already highly stressed with its
abundance of users and I am looking for a more elegant and faster
solution.

What I would like to do is make a .NET library that will wrap the
ASPTypeLibrary.Session. The problem is that since the .NET library
will be invoked from a .NET web page, it won't have any ObjectContext
in order to initialize an object of type ASPTypeLibrary.Session. To
further complicate matters, there is no mechanism that I see that I
can use in order to get a reference to the "legacy" session. I can
read out all of the possible values that my library would need in
order to "feed" the asp library in order to fetch an existing instance
of an ASP 3.0 session (i.e. ASPSESSID cookie, virtual directory actual
path, hostname, ip, relative path, etc, etc, etc). My problem is that
I can't find where I can "feed" all of this info to (or parts thereof)
in order to get what I want back out.

I realize that this may very well delve deeply into
behind-the-scenes-programming-voodoo, and I am fine with that. It
will be very well tested before we let it go out to our production web
servers.

It seems to me you should not WANT to do that.

If your boss gets a new car, that is no reason to ask you as a driver to
get from the old into the new vehicle while driving at 120 km/h and
temporarily transferring the old steering wheel to, and using it in that
new car, even if tested on a private track.

Better make a nice conversion program, if your really need data from the
old system.

It has been said hundreds of times in programming NG's, that the boss is
the patient and you are the doctor, and the patient is not the one that
can order the doctor to do unneccesarily dangerous things to him, even if
possible.

You are the expert, be professional.

 

[Evertjan.]

=?Utf-8?B?TmF0ZQ==?= wrote on 11 jan 2007 in
microsoft.public.inetserver.asp.general:

Thanks for the reply Evertjan. I still have the problem that we are

I have a problem with your topposting on my non topposted reply.

upgrading the ASP app to .NET...

In my personal view, it is just another platform, "upgrading" only in the
commercial blinded eyes of the firm.

If they have convinced you or your boss of the gain, they should be able to
hlp you with the conversion path end interim situation.

In the interim as there is a mix of
ASP and ASP.NET pages running side-by-side in teh same app, I need a
solution for dealing with Session.

They have no session in common, so If you want to have users that are
individually identified as in a "session" while using both asp and aspx
pages, you cannot use the internal session system of either asp or asp.net,
methinks.

That means you will have to develop your own session like coding,
perhaps based on a common ram-cookie that is accessable by both platforms
when under the same domain. [first try if that works, should be easily
tested]. Or you could send an session identifier as a querystring with each
page transfer.

You could ask yourself if the above user identification is really
necessary. If it is for security, I would not trust such temporary buildup.

 

[Mike Brind]

All,

My department has recently been tasked with converting an ASP 3.0 web
application to an ASP.NET 2.0 web application. Currently, in order to
read
values from the ASP 3.0 Session from an ASP.NET web page we have to use a
session bridging technique. There are several techniques out there to
workaround the incompatibility of the 2 session state storage mechanisms
(3.0
vs .NET). The problem that I have with all of the techniques is the extra
time that elapses as we "call" the bridge from the ASP.NET page. The
system
is already highly stressed with its abundance of users and I am looking
for a
more elegant and faster solution.

What I would like to do is make a .NET library that will wrap the
ASPTypeLibrary.Session. The problem is that since the .NET library will
be
invoked from a .NET web page, it won't have any ObjectContext in order to
initialize an object of type ASPTypeLibrary.Session. To further
complicate
matters, there is no mechanism that I see that I can use in order to get a
reference to the "legacy" session. I can read out all of the possible
values
that my library would need in order to "feed" the asp library in order to
fetch an existing instance of an ASP 3.0 session (i.e. ASPSESSID cookie,
virtual directory actual path, hostname, ip, relative path, etc, etc,
etc).
My problem is that I can't find where I can "feed" all of this info to (or
parts thereof) in order to get what I want back out.

I realize that this may very well delve deeply into
behind-the-scenes-programming-voodoo, and I am fine with that. It will be
very well tested before we let it go out to our production web servers.

Have you tried either microsoft.public.dotnet.framework.aspnet, or the
forums at www.asp.net? I'm not saying that no one here uses dotnet, because
I know some do at some level or other. It's just that I suspect that there
will be more people who have migrated from classic asp to dotnet in those
groups that may have faced the same kind of issues.

 

[Evertjan.]

=?Utf-8?B?TmF0ZQ==?= wrote on 11 jan 2007 in
microsoft.public.inetserver.asp.general:

There must be some confusion (on my part for one as to what is meant
by topposting)...

Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

I have 3000+ asp pages (some being include files) that store 50+
variables in session that track various things. I didn't write the
asp app. We are moving to ASP.NET for a myriad of reasons...
performance, security, ease-of-maintenance comparitively, and so on...
For those 3000+ pages, they still need their session. And... my .net
pages need to know what is in that session until we have most of the
pages migrated.

If you don't know how, then that is fine... I don't know either, hence
me asking...

I showed you a way:

That means you will have to develop your own session like coding,
perhaps based on a common ram-cookie that is accessable by both
platforms when under the same domain. [first try if that works,
should be easily tested]. Or you could send an session identifier as
a querystring with each page transfer.

However I am pretty sure you will need to change all
..asp pages for that by adding an include.

I think you are asking the impossible of the people in this NG, not that
it is impossible, but it would take a long time for a skilled and well
payed programmer to develop this. Is your boss inclined to pay for that?

Following Mike's advice to go for dot.net groups is a good one, however.
Probably, succesful "upgraders" along your specs, if they exist, are
bound to reside over there, and not here.

but I'm not in a position to just say "no" to my boss.

Not "just", but he should be glad if you as his professional shows him
the situation, and not tell him fake stories to make him happy.

In the end I think you are better off building all the pages anew at
leasure [well, sort of] on a parallel test site, and go over for
production in one go.

 

[Anthony Jones]

I have 3000+ asp pages (some being include files) that store 50+ variables
in session that track various things. I didn't write the asp app. We are
moving to ASP.NET for a myriad of reasons... performance, security,
ease-of-maintenance comparitively, and so on... For those 3000+ pages, they
still need their session. And... my .net pages need to know what is in that
session until we have most of the pages migrated.

Do the 3000+ pages share a common top level include?

One option is to hijack the Session object in ASP.

Class MySession
Public Property Get Item(Key)
End Prooperty
End Class

Dim Session
Set Session = New MySession

Now anything trying to use the Session object will use MySession instead.

Of course there is still a lot of work to do but it can mean that the only
change you need to make to existing ASP is add an additional include to the
top of the pages, if that. Also if the ASP app uses COM components that are
aware of the ASP script context it could get messy or be impossible.

 

[Mike Brind]

=?Utf-8?B?TmF0ZQ==?= wrote on 11 jan 2007 in
microsoft.public.inetserver.asp.general:

In the end I think you are better off building all the pages anew at
leasure [well, sort of] on a parallel test site, and go over for
production in one go.

That is the most sensible suggestion. If the current site is working, leave
it be while you can build and test the new version. Implementing a
migration in this piece-meal fashion seems daft, especially with the
existing complexity of over 3000 pages.

 

[Anthony Jones]

=?Utf-8?B?TmF0ZQ==?= wrote on 11 jan 2007 in
microsoft.public.inetserver.asp.general:

In the end I think you are better off building all the pages anew at
leasure [well, sort of] on a parallel test site, and go over for
production in one go.

That is the most sensible suggestion. If the current site is working, leave
it be while you can build and test the new version. Implementing a
migration in this piece-meal fashion seems daft, especially with the
existing complexity of over 3000 pages.

That's fine if the requirements of business on the system remain static over
the period that this is done. However in many cases such applications are
constantly in flux with new features and versions of existing features being
needed by the business. If that were not the case what would be the benefit
it porting the app at all?

In some cases it may be sensible to put all new features on hold while you
make massive transition to new technology. I suspect that many would really
struggle to make a strong business case for it though. I can't imagine
telling many of my clients "I can't add any new features for next several
months as I port to a new technology which delivers no new functions for you
but is likely to introduce bugs in things that are currently working"

It therefore would be really useful to have some form of strategy in place
that would allow new features to be developed in new technologies whilst
working in parrallel with existing code. It also allows the porting of
existing code piece by piece as and when resources are available to do it.