Static class in an asp.net application.

[craigkenisston]

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 ?

 

[Scott M.]

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.

 

[John Saunders]

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]

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

 

[craigkenisston]

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.

 

[Hans Kesting]

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

 

[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.

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/d...pp/html/aspnet-pageobjectmodel.asp?frame=true)



Good Luck,

John Saunders

 

[Hans Kesting]

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

 

[John Saunders]

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

 

[Hans Kesting]

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