Reputation: 111

Singleton Pattern in .Net is not possible?

I have a very interesting situation , i have figured out that Singleton pattern is not all possible with .net framework (Any version)

look at this code below

namespace SingletonPattern
{
    class Singleton
    {
    private static readonly Singleton instance = new Singleton();
    private static int mcount = 0;

    private Singleton() {

        mcount += 1;
        Console.WriteLine("Creating {0} instances of Singleton Class", mcount.ToString());
    }

    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

class program
{
    static void Main()
    {
        for (int i = 0; i < 1000; i++)
        {
            System.Activator.CreateInstance(Type.GetType("SingletonPattern.Singleton"), true);
        }

        Console.ReadLine();


        }
    }
}

with the help of System.activator any buddy can break singleton pattern.

so who's at risk ?

any guy who wrote some licensing component where license is implemented as a singleton pattern.

Any server based code which makes use of Singleton pattern.

Maybe I am wrong or my discovery does not make sense but i just wanna share and want to know your views?

Upvotes: 3

Answers (9)

Anand Patel

Reputation: 6421

Check the stack trace in your private constructor to ensure that it is only getting invoked from the Singleton class and not from anywhere else.

using System;
using System.Diagnostics;

class Program
{
    public static void Main(string[] args)
    {
        //This should work and not throw any exception
        Singleton singleton = Singleton.Instance;
        Debug.Assert(singleton != null);

        //This should throw an exception
        Singleton s = (Singleton)Activator.CreateInstance(typeof(Singleton), true);
    }
}

public class Singleton
{
    private static Singleton uniqueInstance = new Singleton();

    private Singleton() 
    {
        StackTrace trace = new StackTrace();
        StackFrame frame = trace.GetFrame(1);

        //Check that the private constructor is only getting invoked by the static initializer, otherwise throw exception
        if (String.Compare(trace.GetFrame(1).GetMethod().Name, ".cctor") != 0)
            throw new InvalidOperationException(
                "Don't call Private constructor on this class. Abide by Singleton semantics.");
    }

    public static Singleton Instance { get { return uniqueInstance; } }
}

Upvotes: 0

markt

Reputation: 5156

If you are concerned about other code attempting to break this pattern, you could use something like a lock, or a semaphore or mutex,etc.. in your implementation to manage the number of instances.

...which might end up making it just a little bit more difficult, as reflection may still be used again to circumvent this...

But - with a locking mechanism, you will take a performance hit, so you have weigh the benefits..

Upvotes: 0

Charles Bretana

Reputation: 146499

if you want to protect against this edge case just change private ctor:

private Singleton() { throw new ApplicationException{
     "Don't call System.Activator.CreateInstance on this class"); }

And then you'll then have to add another parameterized private ctor to actually create the singleton... perhaps with a secret parameter that only the initalizer will know how to pass... entire class would be:

class Singleton
{    
   private static readonly Singleton inst = new Singleton("MySecretWord");    
   private static int mcount = 0;   
   private Singleton(string secret)
   { if (secret != "MySecretWord")  
       throw new ApplicationException{
           "Don't call Private constructor on this class"); 
   }
   private Singleton() { throw new ApplicationException{
     "Don't call System.Activator.CreateInstance on this class"); }
  public static Singleton Instance { get  {  return inst ;  } }
}

But why go to all this trouble ? if someone wants to go to the trouble to break your singleton pattern using CreateInstance, then that's there problem, no?

Upvotes: 2

Daniel

Reputation: 16439

Every client-side licensing scheme can be broken.

You could work around this by throwing an exception if the counter is greater 1 - but then again, the other code could use Reflection to reset the counter. The calling code could even modify your assembly before loading it, completely removing the licensing code!

No programming language, obfuscator, etc. can completely protect you against this - if it was possible, surely game publishers would have already used it to create unbreakable copy protection!

As soon as you've got untrusted code in the same 'security zone' as your code; you've already lost.

Upvotes: 2

JohnFx

Reputation: 34909

I don't think design patterns are a form of security as much as a way to encourage a certain usage. If someone is going to that much trouble to work around the constraints of your design, they get what they deserve.

Upvotes: 4

Joren

Reputation: 14746

To use System.Activator.CreateInstance, you need high permissions. Of course if you're allowed to ignore access modifiers because the system trusts you, then you can break code that depends on consumers respecting access modifiers.

Normally, code does not usually have these permissions.

Upvotes: 7