Hi Peter:
Are you using attach / detach process during debugging?
Changing web.config will definitely force the web application to
reload and re-execute static ctors.
Static variables are scoped to an application domain. There can be
more than one app domain in a process, which is how asp.net can host
mutliple web applications inside a single worker process - each app
gets it's own app domain, and the statics do not interfere with each
other. A static ctor is guaranteed to run no more than once for an app
domain.
If you keep a reference to an object in a static field it will be
there for the life of the app domain (unless you overwrite or null out
the field).
--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 12 Nov 2004 14:44:11 -0800, "Peter Rilling"
<> wrote:
>Here is a weird behavior that I would not have expected in VS.NET during
>debugging. Maybe someone has some insight as to why this is happening.
>
>1) I have a VS.NET web project. This contains a class with a static
>constructor.
>2) The static constructor loads custom information from the web.config.
>3) First time I debug, everything works fine. I hit the breakpoint in the
>static constructor.
>4) I stop debugging. At this point I would have expected all objects to be
>removed from memory.
>5) I start debugging again. This time I do not hit the static constructor.
>6) I make a change in the web.config file.
>7) I start debugging again. This time the static constructor does run.
>
>Why might this be happening? I would have thought that each time I run the
>debugger, it would be starting a new process which would have new variables.
>Static variables I thought were confined to the process in which it is
>running in. Another related question might be, what is the scope and
>lifetime of a static object in an ASP.NET world?
>
>