Public and Internal members in an Internal class?

Ok, so this may be a bit of a silly question, and there's certainly the obvious answer, but I was curious if I've missed any subtleties here.

Is there any difference in terms of visibility/usability between a public member declared in an internal class and an internal member declared in an internal class?

i.e. between

internal class Foo
{
    public void Bar()
    {
    }
}

and

internal class Foo
{
    internal void Bar()
    {
    }
}

If you declared the method as public and also virtual, and then overrode it in a derived class that is public, the reason for using this modifier is clear. However, is this the only situation... am I missing something else?

Consider this case:

public interface IBar { void Bar(); }
internal class C : IBar
{
    public void Bar() { }
}

Here C.Bar cannot be marked as internal; doing so is an error because C.Bar can be accessed by a caller of D.GetBar():

public class D
{
    public static IBar GetBar() { return new C(); } 
}

---

A commenter asked a follow-up question: is an explicit implementation of an interface method considered to be public, or private? (C# does not allow you to put an access modifier on an explicit implementation.)

Take a step back and think about what exactly is "public" or "private" about a member: people think wrong things like "private means that a method cannot be called from outside the class", but that's not true; the class could make a delegate to a private method, pass it to anyone, and they can then call a private method.

Rather, accessibility determines where the name of a thing can be used! Explicit interface implementations do not add a name to the class declaration space in the first place; they can only be referred to by name via the interface, not the class. It really doesn't make sense to think of explicit interface implementations as public or private because they don't have a name you can refer to.

A public member is still just internal when in an internal class.

From MSDN: > The accessibility of a member can never be greater than the accessibility of its containing type. For example, a public method declared in an internal type has only internal accessibility

Think of it this way, I would access a public property on....? A class I can't see? :)

Eric's answer is very important in this case, if it's exposed via an interface and not directly it does make a difference, just depends if you're in that situation with the member you're dealing with.

public members of an internal class can override public members of public base classes and, therefore, be a little more exposed... if indirectly.

Just faced with another example where there is difference between those two, when used from XAML in WPF.

XAML:

<Button Tag="{x:Static vm:Foo+Bar.e1}" />

Code with internal enum compiles successfully:

internal class Foo
{
    internal enum Bar
    {
        e1,
        e2,
    }
}

But surprisingly changing it to public results in error:

internal class Foo
{
    public enum Bar
    {
        e1,
        e2,
    }
}

The last example produces compilation error:

> error MC3064: Only public or internal classes can be used within markup. 'Bar' type is not public or internal.

Unfortunately, I can't explain what's wrong with public in this case. My guess is "just because WPF works that way". Just change modifier of the nested class to internal to get rid of error.

If it comes to reflection it matters if the member is public or not:

For example you even could pass a nested private class to a WPF binding and the binding would work against the public properties just as usual.