Inconsistent accessibility

From your explanations I can understand that I must have a good knowledge about assemblies then only I can grasp the above explanations.

As this thread is too long it will continue in a different thread.

http://www.c-sharpcorner.com/Forums/Thread/226598/assembly.aspx

A multi-file assembly is a single assembly which is compiled by combining several source code files together. Typically, each source code file will contain a separate class or classes.

However, code in these files can access types or members in any other file in the assembly provided that those types or members have internal or public access.

What I'm talking about here is not multi-file assemblies but assemblies which reference each other. Even the simplest assembly will reference (by default) an assembly called mscorlib.dll which contains the basic .NET framework types.

If you create a new console application in Visual Studio and click on References in solution explorer, you'll also see several other assemblies to which references are added by default and you can add your own references to these or remove some if you don't need them.

Normally, when you add references it will be to .dll assemblies but you can also add references to .exe assemblies, if you wish.

The point I've been trying to make in this thread is that the current assembly will have access to the public types and members in referenced assemblies but not to the internal types and members of those assemblies. The compiler therefore needs to take this into account when compiling the current assembly in case it is subsequently used as a referenced assembly itself.

That means code outside the current assembly is referring to a code in another file (Multifile Assembly).  

From the above explanation I can understand that my above program can be technically called as assembly.

Under this circumstance what is meant by "outside". Problem is coloured below.

In the above 3rd thread 4th paragraph sentence is beginning with "This is because code outside the current assembly could………………….."

Not necessarily.

After this (single module) assembly has been compiled, it could (in theory) be added as a reference to another assembly. If code in the latter assembly wanted to call the FlavorScoop method, it would have problems in doing so because it wouldn't have access to the IceCreamCone class.

The compiler is therefore ensuring that these problems won't arise by flagging it as an error now.

In the above explanation 5th paragraph "…..whether in the current assembly or not……"
indicates Multifile Assembly.

.NET programs are technically called 'assemblies'.

Assemblies can either be executables (.exes) or class libraries (.dlls).

The program in your opening post would produce an executable assembly and, whilst that program was running, it would be the current assembly.

The internal access modifier means that only code within the current assembly can access the type or member concerned.

The public access modifier means that any code (whether in the current assembly or not) can access the type or member.

Clearly, if code can access a method then it needs to also have access to the types of the parameters which that method uses. Otherwise, it's not going to be able to call the method.

So, code outside the current assembly attempting to call the public FlavorScoop method also needs access to the IceCreamCone class which it doesn't have because this class is internal. The C# compiler therefore flags it as an 'inconsistent accessibility' error.

In the above 3rd thread 4th paragraph sentence is beginning with "This is because code outside the current assembly could………………….."

Which is the current assembly?

I agree that when you're working with VS or any other IDE it's best not to fiddle with the automatically generated code unless there's a very good reason for doing so.

I think that most developers would agree with those sentiments and, as there isn't a good reason for adding an access modifier to the Main() method, it's best left alone. 

I realised that it is prudent to stick-on to the default access modifier; if you attempt to change it, you will encounter many problems.

How is it in practice, when working in programming filed?

The Program class itself is not public either as it's assumed that you won't want to be using this class from another assembly.

However, it doesn't make any difference what access modifier is used with the static Main method. As this is the entry-point to the application, the CLR can find it even if its private (the default) and consequently this is what you generally see in VS projects and in most other professionally written code.

In Visual Studio Integrated Development Environment public access modifier is not provided in the Main() method only static void Main(string[] args) is there. Is there any reason for that?

It is confusing because by definition public modifier allows unlimited access to a method. I am trying to understand above explanation to clear the confusion.

To be precise, the FlavorScoop method has a default access of private and the IceCreamCone class has a default access of internal.

This is no problem whether the Program class is public or (by default) internal because the FlavorScoop method can only be accessed from within the Program class itself and code within that class has access to the internal class IceCreamCone.

However, if the Program class is public and you make the FlavorScoop method public as well, then this does prevent an access problem.

This is because code outside the current assembly could (in theory at least) call the FlavorScoop method but would be thwarted from doing so because it wouldn't have access to the IceCreamCone class which is internal to the current assembly. External code would not therefore be able to pass the FlavorScoop an appropriate parameter and so the compiler won't allow it in these circumstances.

However, if the FlavorScoop method were public but the Program class were internal, this wouldn't be a problem because the method couldn't then be called by external code. The accessibility of members of a class is always tempered by the accessibility of the class itself and the FlavorScoop method would be effectively internal in this situation.

The problem is that the IceCreamCone class is internal (the default) rather than public.

The FlavorScoop method has a parameter of this type and since it's a public method of a public class this is regarded by the compiler as inconsistent accessibility.

To fix it, make IceCreamCone a public class.