internal vs public in C#

C#.Net

C# Problem Overview


I want to know the difference between the public and internal visibility modifiers.

When should we use internal on a class and when public? I am confused with when a method should be public or internal.

I read that internal can be accessed through the assembly, while public can also be used through the assembly. Then where does the difference lie?

C# Solutions


Solution 1 - C#

public is visible from wherever.

internal is visible only within an assembly.

You tend to use internal only to protect internal APIs. For example, you could expose several overloads of a method:

public int Add(int x, int y)
public int Add(int x,int y, int z)

Both of which call the internal method:

internal int Add(int[] numbers)

You can then put a lot of sophistication on a method, but "protect" it using facade methods that may help the programmer to call the method correctly. (The implementation method with the array parameter may have an arbitrary limit of values, for example.)

Also worth noting that using Reflection, any and all methods are callable regardless of their visibility. Another "hack" to control/gain access to internally hidden APIs.

Solution 2 - C#

internal is useful when you want to declare a member or type inside a DLL, not outside that.

Normally, when you declare a member as public, you can access that from other DLLs. But, if you need to declare something to be public just inside your class library, you can declare it as internal.

In formal definition: internal members are visible just inside the current assembly.

Solution 3 - C#

internal is also useful when writing unit tests. The InternalsVisibleTo attribute lets your test assembly access internal methods in your code assembly. That is, you can test methods that appear private to the outside world without using reflection.

Solution 4 - C#

Public can also be accessed outside of the assembly. So when you have a class that shouldn't be accessed every class in the assembly should be able to access it, then internal is the right thing. If you need outside access, use public.

Solution 5 - C#

Also, properties marked as internal will throw a BindingExpression path error if used for DataBinding in WPF. So those have to be public in order to work properly, even when the DataBinding takes place within the same assembly.

Solution 6 - C#

In general, public methods should meet very high standards for robustness (not crashing or corrupting data due to bad input) and security awareness (not allowing unexpected input to trigger an exploit). But for internal, protected, and private methods, it will often be reasonable to follow more relaxed standards, since one has full control over what inputs each method can receive.

Because parameters passed to a public method (possibly from an external source) are considered less trustworthy than parameters received from within one's own assembly, methods marked as public are often treated differently by code analyzers than otherwise identical methods marked as internal. Just as an example, with a public method the analyzer may warn you to check that the method's parameters are not null. With internal methods, it may be possible to configure the analyzer to be less strict about null checking. Or the analyzer may be able to determine on its own, by doing flow analysis of all the source files for the assembly, that null will never be passed to the particular method as an argument, and thus determine there is no need to check if the parameter is null. There are many other examples of analyzers treating public and internal methods differently.

By correctly marking classes, methods, properties, fields, interfaces, etc. with the correct access modifiers, you correctly signal to code analyzers your intent, and then in return the analyzer can give you more relevant warning messages and advice.

Solution 7 - C#

In a very simple language:

Internal : you will only able to access within a assembly. for ex: if you have created a AccountService.csproj with internal class

public interface IAccount{

  int TotalAmount(long accountID);
}
internal class Account:IAccount{
  
  public int TotalAmount(long accountID){
       ...
   }
}
public class Customer{
   
 public long accountID {get;set;}
 public int GetTotalAmount(){
   IAccount account = new Account();
   return account.TotalAmount(accountID)
 }
}

if you are referring AccountService.csProj to BankService.csProj (BankService.csProj --> AccountService.csproj)

Below are the properties that accessible in BankService.csProj    
Customer.GetTotalAmount() -- Accessible
IAccount.TotalAmount()    -- Accessible
Account.TotalAmount()     -- Not Accessible (as account class is internal)

Solution 8 - C#

If you can Reference the assemble from outside , you have scope of Internal and public classes

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionNoviceToDotNetView Question on Stackoverflow
Solution 1 - C#Program.XView Answer on Stackoverflow
Solution 2 - C#Dr TJView Answer on Stackoverflow
Solution 3 - C#Brian RasmussenView Answer on Stackoverflow
Solution 4 - C#Tomas JanssonView Answer on Stackoverflow
Solution 5 - C#M463View Answer on Stackoverflow
Solution 6 - C#Wayne VanWeerthuizenView Answer on Stackoverflow
Solution 7 - C#ankitView Answer on Stackoverflow
Solution 8 - C#Leroy.PView Answer on Stackoverflow