G
Guest
Background:
We've been using ASP to power our companys intranet ever since around 1998,
and over time we've developed quite a lot of separate web-applications for
different problems. Lately our IT has migrated to Windows 2003 Server and IIS
6.0, and all we've done so far is copy our old ASP files and scripts over and
keep using them.
Unfortunately there have been some problems which we're not able to solve -
it seems as if the old ASP session-handling (using the Session()-object)
stalls the webserver from time to time - static HTML-files are still
delivered, plain ASP-scripts are working, too, but everything using Sessions
is unavailable until the IIS-service is restarted - don't ask me why, as I
said, we were not able to pinpoint the error, it just seems related to
Session-management.
Our workaround right now is to recycle the IIS-process every 30 minutes -
that way the server only stalls every few days. Unfortunately by using this
workaround we lose all Sessions every 30 minutes which is no situation I like.
As ASP.NET offers a "new" Session-handling which doesn't stall the server
we'd like to use it, i.e. we'd like to migrate our existing ASP scripts to
ASP.NET. We don't have the knowledge nor the time nor the manpower to rewrite
all applications from scratch so what we'd like to do is only change the
things that really need to be changed in order for our old scripts to run as
..aspx - even if that means sacrificing performance, the server still has
plenty to spare - if the server runs stable I don't mind a higher CPU
utilisation.
Problem:
As I said, we've started scripting in ASP back in 1998, and in fact there's
still a lot of "old code" and "old concepts" in our scripts, things we just
copied again and again. And one of these "old concepts" is now making it hard
for me to switch existing applications to ASP.NET.
In 1998 we've put together a separate include-file containing all commonly
used functions and variables, and almost every script includes and uses this
file nowadays. My problem is that we've defined quite a lot of global
variables in the include-file, and these variables are also used and required
by almost every script. The Include-file contains things like this:
--snip--
Dim ASPFile
....
ASPFile = Request.ServerVariables( "SCRIPT_NAME" )
....
--/snip--
...and then all scripts including the Include-file can just use "ASPFile" to
reference back to themself like so for example:
--snip--
<form target="<%=ASPFile%>?Action=Submit">
....
--/snip--
Now I know that global variables are probably the second most stupid idea
after the invention of "goto", and I'd really like to rewrite our whole
codebase to get rid of them - but we just don't have the time, so I'm trying
to make these "global variables" work in ASP.NET in some way or another with
the goal to keep the necessary changes to our scripts as small as possible.
Unfortunately I'm quite new to this whole .NET-thing, and while I can see
the good ideas it brings along I'm not able to put them to good use yet, i.e.
I don't know how to use "classes" or "modules" or "inheritance" to end up
with the needed information being available globally.
So if anyone could offer me some advice how to change our Include-file to
make our old global variables "compatible" with ASP.NET without having to
migrate each and every of our existing scripts to strict ASP.NET I'd be
thankful. Small changes are still possible, so it wouldn't be a big problem
to change
<%=ASPFile%>
to something like
<%=GlobalData.ASPFile%>
if the only chance is to encapsulate the global variables inside some sort
of module or class - I'm thinking along the lines of putting something like
this into the Include-file:
--snip--
Public Class GlobalData
Public ASPFile As String
...
ASPFile = Request.ServerVariables( "SCRIPT_NAME" )
...
End Class
--/snip--
...but then I'd still need to know how to correctly instantiate and include
and use this class.
Sorry for this newbish question, but no "ASP to ASP.NET"-migration-howto
seems to address the use of global variables at all, and I've read through
quite a lot of them lately.
Thanks for reading,
Andreas Hofmann
We've been using ASP to power our companys intranet ever since around 1998,
and over time we've developed quite a lot of separate web-applications for
different problems. Lately our IT has migrated to Windows 2003 Server and IIS
6.0, and all we've done so far is copy our old ASP files and scripts over and
keep using them.
Unfortunately there have been some problems which we're not able to solve -
it seems as if the old ASP session-handling (using the Session()-object)
stalls the webserver from time to time - static HTML-files are still
delivered, plain ASP-scripts are working, too, but everything using Sessions
is unavailable until the IIS-service is restarted - don't ask me why, as I
said, we were not able to pinpoint the error, it just seems related to
Session-management.
Our workaround right now is to recycle the IIS-process every 30 minutes -
that way the server only stalls every few days. Unfortunately by using this
workaround we lose all Sessions every 30 minutes which is no situation I like.
As ASP.NET offers a "new" Session-handling which doesn't stall the server
we'd like to use it, i.e. we'd like to migrate our existing ASP scripts to
ASP.NET. We don't have the knowledge nor the time nor the manpower to rewrite
all applications from scratch so what we'd like to do is only change the
things that really need to be changed in order for our old scripts to run as
..aspx - even if that means sacrificing performance, the server still has
plenty to spare - if the server runs stable I don't mind a higher CPU
utilisation.
Problem:
As I said, we've started scripting in ASP back in 1998, and in fact there's
still a lot of "old code" and "old concepts" in our scripts, things we just
copied again and again. And one of these "old concepts" is now making it hard
for me to switch existing applications to ASP.NET.
In 1998 we've put together a separate include-file containing all commonly
used functions and variables, and almost every script includes and uses this
file nowadays. My problem is that we've defined quite a lot of global
variables in the include-file, and these variables are also used and required
by almost every script. The Include-file contains things like this:
--snip--
Dim ASPFile
....
ASPFile = Request.ServerVariables( "SCRIPT_NAME" )
....
--/snip--
...and then all scripts including the Include-file can just use "ASPFile" to
reference back to themself like so for example:
--snip--
<form target="<%=ASPFile%>?Action=Submit">
....
--/snip--
Now I know that global variables are probably the second most stupid idea
after the invention of "goto", and I'd really like to rewrite our whole
codebase to get rid of them - but we just don't have the time, so I'm trying
to make these "global variables" work in ASP.NET in some way or another with
the goal to keep the necessary changes to our scripts as small as possible.
Unfortunately I'm quite new to this whole .NET-thing, and while I can see
the good ideas it brings along I'm not able to put them to good use yet, i.e.
I don't know how to use "classes" or "modules" or "inheritance" to end up
with the needed information being available globally.
So if anyone could offer me some advice how to change our Include-file to
make our old global variables "compatible" with ASP.NET without having to
migrate each and every of our existing scripts to strict ASP.NET I'd be
thankful. Small changes are still possible, so it wouldn't be a big problem
to change
<%=ASPFile%>
to something like
<%=GlobalData.ASPFile%>
if the only chance is to encapsulate the global variables inside some sort
of module or class - I'm thinking along the lines of putting something like
this into the Include-file:
--snip--
Public Class GlobalData
Public ASPFile As String
...
ASPFile = Request.ServerVariables( "SCRIPT_NAME" )
...
End Class
--/snip--
...but then I'd still need to know how to correctly instantiate and include
and use this class.
Sorry for this newbish question, but no "ASP to ASP.NET"-migration-howto
seems to address the use of global variables at all, and I've read through
quite a lot of them lately.
Thanks for reading,
Andreas Hofmann