Singleton class in DLL used on multiple virtual directories

Question

I have the following situation:

• multiple virtual directories under same application pool in IIS
• copy of same DLL in all those directories (same version number)
• a singleton class in one in this DLL

The question is, is this singleton class created only once for all those Virtual Directory instances or is there for each of these directories a separate singleton class.

The code looks something like this:

    [
Transaction(TransactionOption.Supported),
ClassInterface(ClassInterfaceType.AutoDispatch),
Guid("7DE45C4D-19BE-4AA4-A2DA-F4D86E6502A8")
]
public class SomeClass
{
    private static readonly Singleton singleton = new Singleton();

Answer 1

A singleton will be created for each application using it. Each application is separated from each other, because they each exist in their own application domain.

To have a truly singleton class across different applications, you'll need to have them communicate to a common application holding the information (like through remoting or WCF etc.).

The application pool controls how much memory and processor(s) applications in that pool can access (along with the account the programs run under). They are still separate from each other.

Answer 2

In IIs each virtual directory has a single application associated with it. An application does not share memory space with other applications so there will be a new instance of this class for each virtual directory.

You can create a shared application pool which all these applications will use. However, in this case the memory will be shared but each will get a unique process using that memory and each unique process will load the class.

Answer 3

Loading an Assembly (DLL) from different locations into the .net CLR (even an identical copy of the same file into the same process (*)) the CLR treats each of these as separate Assemblies ... so the types in these assemblies - whilst syntactically identical (even in namespace terms) - are still different types!

So even if they were in the same application context (OS process) the singleton would not be a single common instance across the callers (you would have three separate static instances of the same class). Also: an Application Context is defined as having a base path (in the ASP.Net case this is the virtual directory) ... further evidence that the web applications all run in separate processes (Kevin is right).

Just a general point (perhaps off the topic of your question) about copying DLLs, though: the Global Assembly Cache (GAC) comes with different challenges ... but the CLR response to "DLL hell" is to treat every different file (identical copy or not) as a separate assembly ... use the GAC - I would strongly advise against copying assemblies into multiple places on a single machine. If nothing else: such file copying is a deployment nightmare. The GAC comes with all sorts of powerful version management utilities to boot (check out: GAC binding policies).

Hoping to help with your long term solution ...

Aidanapword

(*) this can be done using Reflection ... not a good idea but it happens.

Answer 4

First a note - when you run under IIS 6 and 7, AppDomains can be in separate worker processes if you allow IIS to use multiple processes per AppPool. To put it in proper historical context, AppDomain just emulates what IIS AppPool mechanism would do to any binary. Allows for a lot of scalability and in many cases it doesn't really matter if you have a few copies of a "singleton" - that can improve perf as well.

If you really, really, and I mean really :-) have the need for a server-level singleton there is a way to do it, without paying the cost of remoting, but only if you know your COM or WinNT API.

WinNT route will be the lightest resource-wise but you'll have to do complete WinNT work to the point that you'll start asking why are you still in C# and not C++ - shared memory, events or WinNT mutexes etc.

COM route will require you to force out of proc invocation (proper registry keys) and you may want to go with AutoDual instead of AutoDispatch - first to buy perf and second to make sure that .NET has the minimal chance of trerating that dll as "it's own". The gola is to make it look and quack like any other out of proc COM

Important question to ask yourself is - why do I actually need it? Very different tactics needs to be used if the purpose is caching, vs. fast event processing (in which case MSMQ will serve well - it's now under WCF umbrella).