Quiz: Delegates and private methods

Given the code below, what is the result of the “Direct call” line and the “call via a delegate” lines? And, of course, why? For a little sport, try it without compiling the code first. 


public delegate void Callback();

class Program


    static void Main(string[] args)


        MyClass my = new MyClass();


        //Direct call



        //Call via a delegate

        Callback c = my.GetCallback();




public class MyClass


    public MyClass() { }


    public Callback GetCallback()


        return new Callback(PrivateMethod);



    private void PrivateMethod()


        Console.WriteLine(“Private Method”);



Comments (17)

  1. Hmmm, the direct call does not compile for sure. Second, I guess you meant "return new Callback(PrivateMethod);" in GetCallback, right? In that case, I don’t see why it wouldn’t print "Private Method", else I’m missing something.

    I guess your point is "There is a way to call a private method from outside, given the class gives you a delegate to it", right?

  2. Good catch, I fixed the code in GetCallback()… I should know better than the tweak the quiz right outside of VS 🙂

  3. So is Martin right? It is just to show you can invoke a private method with a delegate?

  4. Well, yea… I am not sure how "tricky" that is… do you think most people get this pretty easily? or is it something we should try to educate them about?

  5. I’d agree that the direct call wouldn’t compile – its a siimple scope error. I think the delegate call would run as its simply holding a reference to the method which is set while in scope and when being called the scope of the refernece isn’t checked.

  6. This quiz is definitely not as tricky as the previous ones but it never hurts to educate people :). A smart co-worker of mine was confused about this exact issue last week, though it was in C++ (which generally makes everything a little more tricky).

  7. Ryan Cromwell says:

    I don’t think it is very tricky, but in general, I have found that our developers have problems conceptualizing delegates.

  8. AT says:

    Short answer – if not C# compiler – then FxCop can list us all thouse tricky private method access via. delegate issues.

    This must allow developers to think twice (or better even more 😉 then puting this code into production.

    But in reality I do not see any realy-big problem here.

    But I will see problems in reverse – if all methods must be public to be consumed by delegate – this will lead to realy unhappy customers 🙁

    P.S> I find this variations of delegate calls cool –

    a) my.GetPrivateMethod()();

    b) Even more (explicit will be much better, but we need crazy code 😉

    public static implicit operator Callback(MyClass m)


    return new Callback(PrivateMethod);


    And using it:



    Callback c = my;


  9. Sean Chase says:

    Honestly Brad, I guess I’ll be the only dummy on this thread and admit that I didn’t knew that was a legal operation. It makes sense why it is though.

  10. Ilya Ryzhenkov says:

    Recently I’ve thought about another quiz, may it will be interesting. So, what’s wrong with this code, or why you’d better use "lock". Assume that SomeList and ExternalClass are defined somewhere.

    public class Program


    public static void Main(string[] args)


    IList list = new SomeList();












  11. Mitch Denny says:

    Hi Brad,

    I think most people understand delegates easily enough, but the relationship with events is less obvious, especially since C# and VB.NET abstract them to some extent.

  12. This one was pretty straight-forward, being able to invoke a private method with a delegate is something I’ve been doing for quite some time.

  13. Ken Brubaker says:

    I don’t see how this is very much different than having private subtypes that are exposed through interfaces–a common pattern. There is a problem with private delegates and serialization, but it’s not the "exposure" issue referenced here. If you want to make FxCop rule, it should not be more than a 25% certainty. I think it is an important reminder, however. Another biggie is if you derive from a type in another assembly, your clients will require access to that assembly. Simple, if you think it through, but I’ve seen several people tripped up by that one. And that one is much to common to FxCop, so documentation is even more important for that one.

  14. I’m a bit confused as to why the big deal is made about the possible various ways classes can get into the non-public methods of other classes. I’ve noticed you’ve made a few posts about the various constructs you might have that allow it to happen.

    I’ve never looked at the public/private/protected/internal decorations in a language to be some sort of security measure. I don’t count on my non-public methods to be absolutely "secure" from being called by an outside program. In fact, using reflection, you can pretty much get into any method with the proper permissions.

    I think developers need to learn more about CAS if they are concerned about malicious code. Depending on the declared accessibility modifiers to protect your code seems like a bad practice from the get-go.

  15. The big deal I think has more to do with OO design than security.
    <br>It violates the principle of encapsulation when a client is able to call private methods and access private fields. I think that is a big deal.
    <br>Although it is possible to call private methods etc… I think in general it’s a bad practice. Of course, there are those rare cases where you just have to.

  16. Joshua Rowe says:

    Of course, CAS and public / protected / private methods go hand in hand. You need specific CAS rights to access protected / private methods of other classes through reflection. Thus, marking a method as private protects that method from being referenced by untrusted code (code w/o ReflectionPermission), unless a delegate is somehow exported from the class or the private method is also marked as virtual.