Simply a Singleton - in C# .NET

[Chuck Duncan]

I have implemented singleton classes many times in the past without a problem. Perhaps dimentia is setting in, but today I found I couldn't make it work.
I'm using Visual Studio 2008, C#, and started with a simple:

    public class justOne
    {
        private static justOne _justOne = null;

        public static int LocalCounter;

        private justOne() { LocalCounter = 0; }
        public justOne getJustOne()
        {
            if (_justOne == null)
                _justOne = new justOne();
            return _justOne;
        }
    }

I run a small app in the same solution and watch it start. From a similar program (different solution), I reference the same class library, but it creates a new instance even though the first one is still running.

I read http://msdn.microsoft.com/en-us/library/ff650316.aspx and tried every variation suggested, but no luck.

Okay, where did I go wrong?

Thanks in Advance! :-)

[Chuck Duncan]

A typo in my transcription

I did notice: I had forgotten to add static in the singleton class function. It should read:
public static justOne getJustOne()

:-)

[Chuck Duncan]

Further observation

I found that if I call getJustOne multiple times in the same application, I do - in fact - get just the same instance. What I want/need is for this to work regardless of how many different applications access the same class library (dll). This is what isn't working.

Thanks.

[Chuck Duncan]

To answer my own question: a simple singleton as I described above will be instantiated as a new class instance across different processes UNLESS I incorporate some method of remoting such as WCF.... Thus, I will be adding WCF to the mix.

[Alex Papadimoulis]

You are correct; it is logically impossible to have code executing in different processes share the same memory space (and therefore, an instance of an object). When a new process starts up, it gets its own stack/heap space.

Inter-process state-management is the only way to do this, and a server process (such as a WCF endpoint) can function in this capacity.

Alternatively, you could maintain the state in a database. This might be easier and prefered as it will be more reliable (consider: if the application crashes/restarts) at maintaining your state data.