What is the memory footprint of static methods of a windows app running on a
server when the server spins up multiple instances of the application?

In my envirionment, we have a Citrix server farm running .Net 2.0 windows
apps. Does the framework allow for instances of the same application to
access the same memory space where static methods are stored (assuming the
security context is the same for each instance)?

"Todd" <Todd (AT) discussions (DOT) microsoft.com> wrote

need for a good answer, so I'm crossposting this to a framework group.

On Fri, 01 Jun 2007 20:03:41 -0700, pvdg42 <pvdg42 (AT) newsgroups (DOT) nospam>
wrote:

Though, I'm reading this from the m.p.d.framework newsgroup and I can't
say that I really understand the question. What, for example, is the
point about asking about static methods versus other methods? It's not
like when you instantiate a new instance of a class, new copies of the
code that goes with that class are created too.

If there is really some distinction between static and instance methods
here that's important to the question, perhaps the OP could be more clear
about that. On the face of it, it's not readily apparent why he's asking
only about static methods.

Anyway, I'm no expert and hopefully someone who is will correct/elaborate
as necessary. However, my recollection is that Windows doesn't even share
physical memory between native applications. What it does do (again, if I
recall correctly) is avoid copying executable read-only code to the swap
file, using the original executable file as the backing store for virtual
memory. I would guess the .NET Framework can also do this, so at least
multiple instances don't eat up your swap file. But I would be
(pleasantly ) surprised if multiple .NET applications could all be
resident, sharing the same physical RAM containing the executable code.

Pete

Based on your last paragraph, it appears you understood what I was asking.
And I guess my question does extend past only static methods. I'll try
posting in the dotnet.framework group. Thanks for your response.

"Peter Duniho" wrote: