Singleton Referencing

Question

Okay...I have a situation where a C# .dll is a singleton. Now, what I want to be able to do is when the singletonInstance is instantiated be able to provide a reference to any other applications that may start. So, I looked up NamedPipes and that would work - except for one thing, this must be cross-platform, or platform independent. I have a solution in mind, but I am having a hard time trying to figure out if I can derive a reference to the singletonInstance either through a handle, or some other method?

Now that there have been a few comments and questions, I can explain a little more and clarify: what I have is basically a commonly shared resource (my singletonInstance.dll). Say appA needs that singletonInstance, if it isn't yet instanced, it will instance it. Then appB is started, and it needs a reference to the singletonInstance. That is the scenario.

Answer 1

If I'm reading this correctly, you should manage the instance on a server and have the other applications talk to the server instead of the object itself. Web services is the first thing that comes to mind but I don't know enough about your problem.

Answer 2

Well, you can comunicate through named pipes and when they're no available you can go to sockets, but it depends on what actually your "singleton" is going to do. Is it some kind of shared cache? Or what?

Will separate applications and "singleton" run on same machine or in network? Anyways socket's approach is good if you want to control low level implementation or you can go to webservices with some overhead or use remoting.

Answer 3

I'll offer up an answer - Runtime.Remoting.Channels. I had a common data object (the 'singletonInstance') inherit MarshaByRefObject. This gives us exactly what we want, plus we are making it capable of some networking features. Right now, this really acting like a service. The TcpChannel 'Server' is actually part of the .dll where the common data object is. This is mostly just for testing, experimental implementation, and so on.

Answer 4

It sounds like you're better off implementing whatever needs to be shared as a service.

You can connect to the service in a variety of ways that you choose to expose / implement / allow. Web Services, WCF, Named Pipes or raw sockets, etc. Choose whatever works best for you.

The service itself can then manage it's internal state appropriately (singleton anti-patterns or otherwise, it's irrelevant).

Think about how Sql Server is architected. It's not sharing the same dll instance across processes and memory boundaries, nor is it using heavy clients.