Sharing Session State

I would like to develop an asp.net Web application using muliple web project
s under one solution file and share the session information between web appl
ications( or projects). Is this possible?Yes, instead of using Session state, you can use Application state, i.e. you
save to the Application object which is shared among all Web apps on the
server. Alternatively you can implement your own component with shared data.
Carsten Thomsen
Enterprise Development with VS .NET, UML, and MSF
http://www.apress.com/book/bookDisplay.html?bID=105
"grooby" <anonymous@.discussions.microsoft.com> wrote in message
news:3061A87E-4F03-4712-AEB7-DA678E6B7A32@.microsoft.com...
>I would like to develop an asp.net Web application using muliple web
>projects under one solution file and share the session information between
>web applications( or projects). Is this possible?
Hi. I've seen this question a bunch of times, and I was interested in it as
well, so I tried to pull together everyone's info.
Session state cannot (and should not) be shared because it would be unsecure
to do so. In fact, session data isn't completely secure unless you force a
n SSL connection. Even then, there are issues with older versions of IIS (5
.1 and below) where your se
ssion state is lost of you browse from an SSL connection to a non-SSL connec
tion, or vice versa.
Using the application object will persist data in the application collection
and make it available to all sessions in an app, but there's no way to rest
rict access.
So, alternatives to sharing session state seem to be:
- Use a SQL database to persist session variables at the end of each session
. This allows for access restrictions. You can use the client's cookie as
an identifier if you wish. (from 2 seperate posts)
- Implement your own COM component with shared data. Your apps would call t
hat component.
- Use a message queuing system like MSMQ to save or cache data in a "queue w
hich can either
reside locally or on a dedicated server. Any application can read the queue
once it knows the path to the queue - it typically does
You can store the message in any format from text, to
full blown datasets or custom objects. You can think of the msmq as a robust
caching strategy over a network. It's a good approach because the msmq can
be configured to be fail safe (survive reboots), back up messages, provide
confirmation etc. In addition, msmq can be programmed in a line or two, but
it does require the msmq service to installed and running on the machine."
(from "How can I share cached data between web clients?")
- Use the solution in the article at http://www.asp101.com/articles/jayr...te/default.asp. However, one poster said, "you can do what the article sug
gests without
the massive delete, edit the .webinfo file crap if you set up the parent app
and make the other "apps" subdirs of the parent app (importing, if child
apps already completed). This is really a non-solution for most of us, as
you are essentially killing the child apps and making a single parent app
with all of your applications. You cannot set up the application on a unique
CName, like app1.mydomain.com, as it is tied to the other apps*. Yuck"
A good topic on MSDN is "State Management Recommendations" at http://msdn.microsof
t.com/l...r />
tion.asp. It outlines some of the options above.
"CT" wrote:

> Yes, instead of using Session state, you can use Application state, i.e. y
ou
> save to the Application object which is shared among all Web apps on the
> server. Alternatively you can implement your own component with shared dat
a.
> --
> Carsten Thomsen
> Enterprise Development with VS .NET, UML, and MSF
> http://www.apress.com/book/bookDisplay.html?bID=105
> "grooby" <anonymous@.discussions.microsoft.com> wrote in message
> news:3061A87E-4F03-4712-AEB7-DA678E6B7A32@.microsoft.com...
>
>
Hi. I've seen this question a bunch of times, and I was interested in it as
well, so I tried to pull together everyone's info.
Session state cannot (and should not) be shared because it would be unsecure
to do so. In fact, session data isn't completely secure unless you force a
n SSL connection. Even then, there are issues with older versions of IIS (5
.1 and below) where your se
ssion state is lost of you browse from an SSL connection to a non-SSL connec
tion, or vice versa.
Using the application object will persist data in the application collection
and make it available to all sessions in an app, but there's no way to rest
rict access.
So, alternatives to sharing session state seem to be:
- Use a SQL database to persist session variables at the end of each session
. This allows for access restrictions. You can use the client's cookie as
an identifier if you wish. (from 2 seperate posts)
- Implement your own COM component with shared data. Your apps would call t
hat component.
- Use a message queuing system like MSMQ to save or cache data in a "queue w
hich can either
reside locally or on a dedicated server. Any application can read the queue
once it knows the path to the queue - it typically does
You can store the message in any format from text, to
full blown datasets or custom objects. You can think of the msmq as a robust
caching strategy over a network. It's a good approach because the msmq can
be configured to be fail safe (survive reboots), back up messages, provide
confirmation etc. In addition, msmq can be programmed in a line or two, but
it does require the msmq service to installed and running on the machine."
(from "How can I share cached data between web clients?")
- Use the solution in the article at http://www.asp101.com/articles/jayr...te/default.asp. However, one poster said, "you can do what the article sug
gests without
the massive delete, edit the .webinfo file crap if you set up the parent app
and make the other "apps" subdirs of the parent app (importing, if child
apps already completed). This is really a non-solution for most of us, as
you are essentially killing the child apps and making a single parent app
with all of your applications. You cannot set up the application on a unique
CName, like app1.mydomain.com, as it is tied to the other apps*. Yuck"
A good topic on MSDN is "State Management Recommendations" at http://msdn.microsof
t.com/l...r />
tion.asp. It outlines some of the options above.
"CT" wrote:

> Yes, instead of using Session state, you can use Application state, i.e. y
ou
> save to the Application object which is shared among all Web apps on the
> server. Alternatively you can implement your own component with shared dat
a.
> --
> Carsten Thomsen
> Enterprise Development with VS .NET, UML, and MSF
> http://www.apress.com/book/bookDisplay.html?bID=105
> "grooby" <anonymous@.discussions.microsoft.com> wrote in message
> news:3061A87E-4F03-4712-AEB7-DA678E6B7A32@.microsoft.com...
>
>