Static class in an asp.net application.

Hi,

I'm starting my first asp.net application and I decided to put the
users preferences in a static class.
I thought, the static class would be just seen by current session, but
it seems it don't work like that (!?).

If I change some preference and I open a second browser session, even
another browser (netscape, opera), it seems the preferences are shared
like a big cookie among all browsers.
Thought, it is not perfectly consisten, sometimes, they do show the
same preference and some times they don't. Opera seems to be very
stubborn to read the preference when they were set through other
browser.

Well, the question is, what is the life of an static class in an
asp.net application ? is it session wide ? or it is instantiated once
for all users connected ?

craigkenisston@hotmail.com

> Well, the question is, what is the life of an static class in an
> asp.net application ?


> or it is instantiated once for all users connected ?

Yes.

For storing user preferences, you should use cookies or if your users have
to log in, you can write their preferences into a database. Then, at login,
you can restore their preferences. Cookies are the simplest solution but be
aware that some users may have cookies disabled and that cookie data isn't
secure.

Scott M.

<> wrote in message
news: oups.com...
> Hi,
>
> I'm starting my first asp.net application and I decided to put the
> users preferences in a static class.
> I thought, the static class would be just seen by current session, but
> it seems it don't work like that (!?).
>
> If I change some preference and I open a second browser session, even
> another browser (netscape, opera), it seems the preferences are shared
> like a big cookie among all browsers.
> Thought, it is not perfectly consisten, sometimes, they do show the
> same preference and some times they don't. Opera seems to be very
> stubborn to read the preference when they were set through other
> browser.
>
> Well, the question is, what is the life of an static class in an
> asp.net application ? is it session wide ? or it is instantiated once
> for all users connected ?

John Saunders

<> wrote in message
news: oups.com...
> Well, the question is, what is the life of an static class in an
> asp.net application ? is it session wide ? or it is instantiated once
> for all users connected ?

What's the life of a static class in any application? Why would ASP.NET be
any different.

static (or Shared) members have one existence for all instances of a class
within an AppDomain. This is the opposite of an instance member, which has
one copy for each instance of a class.

This is exactly the case in ASP.NET.

If you want something which will be per-session, then you should use Session
state. If you want something which will be global to the entire application,
use Application state. Neither one is thread-safe, so be careful.

John Saunders

John Saunders

John :

Thanks for your answer. It is a bit more clear now.
Still I've not found an black&white response to following, not even in
the documentation :
what is the life of the asp.net dll ?
I don't think it is exactly like any other application :
I have a C# winform application, it has some static class. If I run my
application twice, I still having different copies of the static
classes in each of the executables.
However, here asp.net seems to share the dll data among the
connections, so, you know it is a little bit different concept,
specially when comming from win32 client applications.

craigkenisston@hotmail.com

wrote:
> John :
>
> Thanks for your answer. It is a bit more clear now.
> Still I've not found an black&white response to following, not even in
> the documentation :
> what is the life of the asp.net dll ?
> I don't think it is exactly like any other application :
> I have a C# winform application, it has some static class. If I run my
> application twice, I still having different copies of the static
> classes in each of the executables.
> However, here asp.net seems to share the dll data among the
> connections, so, you know it is a little bit different concept,
> specially when comming from win32 client applications.

If you start your winform app twice, you have two separate applications running.

An ASP.Net application is a *single* application running on a webserver,
serving *multiple* (possibly simultaneous) requests.
The application is started with the first request. I'm not sure exactly when
it finishes, it's either "never" or "after the last session has expired"
(which is default 20 minutes after the last request has been served).
Maybe someone else has a good answer here?

Hans Kesting

Hans Kesting

<> wrote in message
news: oups.com...
> John :
>
> Thanks for your answer. It is a bit more clear now.
> Still I've not found an black&white response to following, not even in
> the documentation :
> what is the life of the asp.net dll ?
> I don't think it is exactly like any other application :
> I have a C# winform application, it has some static class. If I run my
> application twice, I still having different copies of the static
> classes in each of the executables.

If you run your windows application twice, you've got two separate
AppDomains, one in each process.

There is no ASP.NET equivalent to that. When a user accesses an ASP.NET web
site, ASP.NET doesn't start up a new process to run the web application, nor
does it start a new AppDomain (assuming that one is already running).
Multiple requests are serviced within the same AppDomain, therefore,
multiple requests will see the same copy of Shared data.

> However, here asp.net seems to share the dll data among the
> connections, so, you know it is a little bit different concept,
> specially when comming from win32 client applications.

Very true.

I have wondered about the path that persons like yourself take in coming
from Win32 applications to ASP.NET. Not to sound too harsh, but how did you
NOT know that an ASP.NET application is so different from a Windows Forms
application? What documentation did you look at when getting started in
ASP.NET? Whichever documentation you used, it needs to have a big Stop sign
on the cover of it saying: READ THIS FIRST: WEB APPLICATIONS ARE DIFFERENT.

You are only the tenth person this month I've seen with this same problem,
and that's probably because I can't remember numbers 11 through 20! I'm not
picking on you, rather I'd like to find out what's causing this, perhaps in
time for Microsoft to add that Stop page before VS2005 ships.

In the meantime, here's where the Stop page should point to:

The ASP.NET Page Object Model
(http://msdn.microsoft.com/library/de...asp?frame=true)



Good Luck,

John Saunders

John Saunders

> You are only the tenth person this month I've seen with this same
> problem, and that's probably because I can't remember numbers 11
> through 20! I'm not picking on you, rather I'd like to find out
> what's causing this, perhaps in time for Microsoft to add that Stop
> page before VS2005 ships.

It's probably because VS / .Net can handle both types of application,
so it's easy to try out the "other" one. I personally have a similar
problem in reverse: things that are easy in asp.net (screen generation mostly)
are very different in a winform application.

Hans Kesting

Hans Kesting

"Hans Kesting" <> wrote in message
news:...
>> You are only the tenth person this month I've seen with this same
>> problem, and that's probably because I can't remember numbers 11
>> through 20! I'm not picking on you, rather I'd like to find out
>> what's causing this, perhaps in time for Microsoft to add that Stop
>> page before VS2005 ships.
>
> It's probably because VS / .Net can handle both types of application,
> so it's easy to try out the "other" one. I personally have a similar
> problem in reverse: things that are easy in asp.net (screen generation
> mostly)
> are very different in a winform application.

Oh, well, in this case documentation wouldn't have helped, because you
didn't read any before starting!

John Saunders

John Saunders

John Saunders wrote:
> "Hans Kesting" <> wrote in message
> news:...
>>> You are only the tenth person this month I've seen with this same
>>> problem, and that's probably because I can't remember numbers 11
>>> through 20! I'm not picking on you, rather I'd like to find out
>>> what's causing this, perhaps in time for Microsoft to add that Stop
>>> page before VS2005 ships.
>>
>> It's probably because VS / .Net can handle both types of application,
>> so it's easy to try out the "other" one. I personally have a similar
>> problem in reverse: things that are easy in asp.net (screen
>> generation mostly)
>> are very different in a winform application.
>
> Oh, well, in this case documentation wouldn't have helped, because you
> didn't read any before starting!
>
> John Saunders

Of course! I'm a developer, so I don't read documentation

Hans Kesting