static variables in asp.net/C#

I'm using extensively static variables in my web application project. Now I have read from some articles that it is a global variable for the whole project and the data that is in the static variables can be shared or overwritten by other users (I mean it is not user specific or session specific).

So is it general programming practice not to use static variables in the normal web application development?

Are static variables not used at all just like GOTO statement/keyword meaning there are extensive restrictions to use them and preferably not used at all? Then in what cases do we use the static key word?

Then i have this requirement that a particular variable has to be initialized only once in a particular webform.aspx.cs and the scope has to be restricted to only to that particular .aspx.cs and to that particular user who has logged in ? How do i meet this requirement ? If possible can any one illustrate this with code ?

Personally I try to avoid static variables as much as possible. They make the code difficult to unit test and also could introduce subtle bugs due to concurrent access and race conditions.

As far as your requirement is concerned you could use store the variable as a property of the control in the ViewState. If it is user specific data that you are trying to store then you could use the Session state.

I believe your interpretation of static is wrong.

Use the static modifier to declare a static member, which belongs to the type itself rather than to a specific object.

In other words, there is only one instance of this member for all the specific instances of the class.

There isn't anything wrong with static variables as long as you use them correctly. I believe you are mixing static with global variables. Global variables can be accessed from everywhere. This isn't desireable since knowing when and where the state of that variable is set is complex. Furthermore this makes unit testing more difficult.

This Programmers.SE question probably interests you.

On static's, there are various reasons why they should be avoided in general, although they do have their specific uses.

Then i have this requirement that a particular variable has to be initialized only once in a particular webform.aspx.cs and the scope has to be restricted to only to that particular .aspx.cs and to that particular user who has logged in ? How do i meet this requirement ? If possible can any one illustrate this with code ?

For this requirement, I would suggest you look at clarifiying the requirement:

• is this once per user? If so, then look at using the Session object provided by ASP. Sample code for Session is http://msdn.microsoft.com/en-us/library/ms972429.aspx
• or is this once per page per user? i.e. if the same user has two browsers open on the same page, then will the user have two objects? If so, then look at using ViewState within the page. overview of ViewState is http://msdn.microsoft.com/en-us/library/ms972976.aspx

Personally I prefer using Session - with ViewState it's very easy for things to go wrong, and when they do go wrong it can be very hard to debug!

explanation of: "when they do go wrong it can be very hard to debug" - ViewState can be configured to works several ways, but generally it's set up to work by serializing objects into the client pages as Hidden form fields and then subsequently deserializing these objects when the page PostBack occurs. I've spent many many days debugging a certain DNN based website which had "Invalid ViewState" problems only on some browsers, only on some pages and only some of the time. What caused this? After several days I still didn't know... hence why I stay clear of ViewState if I can. However, I admit that this might be an unfair decision - in my case, I was working with a lot of third party code which generated dynamic pages and which created a lot of ViewState (size and complexity of ViewState is actually one of my reasons for not using WebForms at all if I can).

How about using the session ..

For example if you have some services then you can use it as static because no need for the IIS to create repeated object for services because they all are same :)