Is `internal` the same as `public` for a single project?

In a single project (ie assembly) is the internal attribute any different from the public attribute?

I don't see a difference, but I wanted to make sure there are no edge cases I am not thinkin开发者_C百科g of.

---

Yes, the difference comes in when somebody else is referencing your assembly. In that case only the public members will be visible. But don't forget, the internal/private members can still be accessed via Reflection/dynamics. Also it will no longer be labeled with the BindingFlags.Public, it uses BindingFlags.NonPublic instead.

---

Yes, it's the same. Internal is public within the same assembly so if you have a single assembly there is no difference

---

Lots of people are saying yes, but the answer really is no.

If somebody references your assembly then there is a very big difference!

---

In general, yes.

In very rare cases, there may be differences, especially in reflection-specific contexts. For example, Activator.CreateInstance(typeof(myType)) will succeed if the type has a public parameterless constructor, but may not if the type only has an internal one (atleast on .NET 3.5) - you will have to call the overload with nonpublic = true.

Also, note that interface implementations are always public. Consequently, Replace all -> "public" - "internal" from your editor may produce code that does not compile - the compiler will refuse to allow you to implement an interface's member with internal visibility.

---

From with the assembly in which it is declared it is the same.

---

Yes, basically internal means that classes can be only used inside your assembly, which will work the same way as public inside the assembly.
But if you think your assembly will be used by any projects, its better to use public on the classes that can be referenced.

Also if you declare a class as internal, and some method inside public, internal will override its accessibility, making it internal.