We Keep Coding

Why is a program main method static?

I always thought (assumed) that the Main method was static because you cannot have multiple instances of it (Correct me if that's wrong). The Main method is the start point of your program and thus you can have only one.
So if I have
class Program
{
static void Main(String[] args)
{ // something
}
}
class OtherClass
{
void Test()
{
Program p1 = new Program();
Program p2 = new Program();
Program p3 = new Program();
Program p4 = new Program();
}
}
all instances of Program will share the same Main method and so there will always be one start point.
Am I correct? Because I just googled this out of curiosity and found DIFFERENT answers to it on the Internet.
Is this explanation ALSO correct for the main method being static?

If the entry point method were not static, someone would need to create an object first. The question is then: create an object of which class?
I always thought (assumed) that the Main method was static because you cannot have multiple instances of it
You can't have instances of methods. Methods reside in the Code section of a DLL and are not copied to the heap. You can only have multiple threads running in the same method.
The Main method is the start point of your program and thus you can have only one.
As before: If we consider signatures, there is only one method, independent if it's static or not, because they are not instantiated.
all instances of Program will share the same Main method ...
Depends on what you understand by the term "share". All objects will have the method, yes.
... and so there will always be one start point.
The reasoning behind it is wrong. You have many instances of Program but that doesn't matter to the amount of methods.

Static initializers vs static constructors, execution orders, release mode behaving oddly

I've read several of the other posts here about this, but my problem seems to fly in the face of the general wisdom posted here (Is the order of static class initialization in C# deterministic?) and several related posts.
I've got an ASP.Net 4.0 application, and my Application_Start() method runs through touching a lot of things to get them set up. One of those things is initializing our db connection string for our DAL, others initializing other variables. A couple of days ago our release builds started blowing up, and after adding a lot of debug logging, the cause turned out to be a new static initizalizer being called before Application_Start() was officially entered and trying to access our DAL before it was initialized. And this seems to run afoul of what I see in other posts here about the order of execution for static constructors and initializers.
Specifically, the static initializers are not being run at the point in the code where they are called; the stack traces in the release build indicate that release compilation shuffles them up to be part of entering Application_Startup(). In other words the stack trace when it blows up shows Application_Startup() on the stack - but no line number associated with it. The stack trace for the DAL initialization does show the line number.
To flesh out some pseudo code, we have
Application_Start()
{
DAL.Inst.GetSetting("ConnectionString"); // tickles the singleton to get the DAL initialized.
// numerous other lines of code
if (!AppUtil.IsAdminAccountSetup)
{ // Do admin account setup
}
// More code
}
public class DAL
{
private static DAL _singleton;
static DAL()
{
_singleton = new DAL();
_singleton.Initialize();
}
public static DAL Inst
{
get { return _singleton; }
}
// all the other methods
}
public class AppUtil
{
private static bool _isAdminSetup = InitializeAdminSetup();
public static bool IsAdminAccountSetup
{
get { return _isAdminSetup; }
}
private static bool InitializeAdminSetup()
{
// Call DAL for query
}
private static bool _isProductRegistered = InitializeProdReg();
public static bool IsProductRegistered
{
get { return _isProductRegistered; }
}
private static bool InitializeProdReg()
{
// Call DAL for query
}
}
AppUtil recently had the IsProductRegistered boolean added, and that seems to be when things headed south.
AppUtil.IsProductRegistered is not called in Application_Start(), but when we look at stack traces about the order of queries to the DAL, we see the initializer for AppUtil.IsProductRegistered calling the DAL (before DAL.Inst gets touched) and from Application_Start() (no line number).
Then we see the connection string getting initialized as part of the DAL static constructor, and that traces back to the DAL.Inst reference in Application_Start() - and here it does show the line number.
If we change both of the static initialzers in AppUtil to a single static constructor, things go back to being initialized in reference order and the blow-up goes away.
But the whole situation flies in the face of what I've read about what .Net says it will do.
Sorry for the information barf, but I hoped to have enough detail to make the conundrum clear.

There is a big difference between initializers on a class with a static constructor and without. On classes without a static constructor they can run at any time prior to the first access, much earlier if the runtime so decides. With a static constructor they can only run immediately prior to the first access.
DAL has a static constructor so it's guaranteed to initialize on first access and no earlier.
AppUtil has no static constructor, so it can run as early as it likes, in particular it can run before you initialized DAL.
Your immediate problem should disappear if you add a static constructor to AppUtil even if it's empty.
You should read C# and beforefieldinit by Jon Skeet, where he explains this difference in detail.
To quote the specification:
If a static constructor (§10.12) exists in the class, execution of the static field initializers occurs immediately prior to executing that static constructor. Otherwise, the static field initializers are executed at an implementation-dependent time prior to the first use of a static field of that class.
The static constructor for a closed class type executes at most once in a given application domain. The execution of a static constructor is triggered by the first of the following events to occur within an application domain:
An instance of the class type is created.
Any of the static members of the class type are referenced.
Still this kind of initialization pattern is a bad idea on many levels. These initializers are hard to debug, can change their order on a whim.
You should not use static fields for this kind of state in the first place. Create a single instance of these classes during your initialization code instead of using a classic singleton which uses state from outside its own class to initialize. Or even better, use proper Dependency Injection. These kind of services is the place where DI and IoC shine.

In addition to Loki's comments.
You are potentially going to burnt very badly if dependant on statics in a DAL. eg Entity framework.
Do not attempt this without understanding the .Net ASP pipeline and how threads are used.
You must consider what is going on in the app pool. The lifetime of the app pool. Thread safety. The app pool allocates incoming calls to threads. So you must make the statics thread safe.
You may need a custom initializer that gets called for every request no just on APP start.
As you are discovering app start could already have run on a previous request.
for your consideration:
//Global asax handlers
public override void Init() {
base.Init();
// handlers managed by ASP.Net during Forms authentication
BeginRequest += new EventHandler(BeginRequestHandler);
// PostAuthorizeRequest += new EventHandler(PostAuthHandler);
EndRequest += new EventHandler(EndRequestHandler);
}
Consider
ASP.NET controller constructors that "renew" contexts left over from last call.
Consider how you will protect your static. // thread safe ????
private static Object _bgalock = new Object();
[ThreadStatic] // thread based static to avoid disasters....
private static sometypeStaticUsedGlobally _ouch;
// Then Get and Set static with lock

Why should the Main() method be static?

I tried to create public void Main() in C#; it says no static void Main found.
What exactly does it mean for Main to be static? I know the code works fine for public static void Main().
But why does Main have to be static?

You need an entry point into your program. Static means that you can call the function without having to instantiate an object/instance of a class. It's a bit "chicken and egg"... you can't instantiate an object before you're inside the program.
A static method can be called without instantiating an object. Therefore main() needs to be static in order to allow it to be the entry to your program.
As David says, you can just add the keyword static to the function definition to change it. It's worth looking into static (class) methods vs instance methods, and knowing the difference can be useful at times.

Only the static main method can do the job because there is a convention that defines this behavior. There is not another reason.
Take a look at the C# language specification:
Application startup occurs when the execution environment calls a
designated method, which is referred to as the application's entry
point. This entry point method is always named Main, and shall have
one of the following signatures:
static void Main() {…}
static void Main(string[] args) {…}
static int Main() {…}
static int Main(string[] args) {…}
As shown, the entry point can optionally
return an int value. This return value is used in application
termination (§10.2).
Note: The above is quoted from the 4th edition, now labeled "historical". The current edition is worded differently.
In addition to that, the name Main can be changed to something else. In this case a compiler option must be added telling the C# compiler to mark a different method as the entry point of the program.

There are two types of method within a class:
Non-static method
Static method
// Example of static and non-static methods and how to call
namespace TestStaticVoidMain
{
class Program
{
Static Void Main(string[] args)
{
// Instantiate or create object of the non-static method:
Exam ob = new Exam();
// Call the instance:
ob.Test1();
// Directly the call the static method by its class:
Exam.Test2();
Console.ReadKey();
}
}
class Exam
{
public void Test1()
{
Console.WriteLine("This is a non-static method");
}
public static void Test2()
{
Console.WriteLine("This is a static method");
}
}
}
1. Static method:
To call a static method (function), we don't need to instantiate or create an object of that method. We can't use new keyword because, when the class is loaded and compiled, the static keyword by default instantiates or creates an object of that class method, so that is why we directly call a static method.
In reference to static void Main(string[] args), we already discussed static. The remainder is void Main(string[] args). void is a data type which returns nothing. Main() is the standard entry point to execution of a C# program. The optional argument string[] args receives the optional "command line" parameters that the program was run with.
2. Non-static sethod:
To call a non-static method, we have to instantiate or create an object of the class method to call the method (function) of the class using the keyword new.
If a class named Test has a non-static method named show(), then how it would call an instance:
// to call non-static method
Test ob=new Test();
ob.show();

Conceptually, it would be possible for a framework to specify that rather than using a particular static method to run a program, it will instead construct a default instance of some particular class and run some particular method thereon. If one had a framework which implemented static methods by having them be instance members of a compiler-initialized singleton instance, such an approach might be entirely reasonable, since the framework would have to generate a new object instance before calling the main function in any case.
If calling a static method is "easier" than constructing a new object instance and calling a method thereon, however, there isn't really much benefit to requiring that a framework use the more expensive course of action. Any code which wants to use the latter approach would be perfectly free to use:
public static void Main( [[params]] )
{
var mainObject = new MainObject();
mainObject.Main( [[params]] );
}
There could be some potential benefits to having the system include its own static method which looked something like:
public static void SysMain( [[params]] )
{
using (Application app = new UserApp( [[params]] )) // UserApp derives from Application
{
app.Start(); // Virtual method
app.AllowNext(); // Base method--see text
app.Run(); // Abstract method
}
}
where app.AllowNext() was a method to coordinate with other application instances launched at essentially the same time, to ensure that repeated attempts to launch an application in background would have their Start calls processed strictly sequentially. Absent such a coordination scheme, however, there's not really much benefit to requiring that the framework construct an application object before running it. The cost wouldn't be huge, but without any potential identifiable benefit there's not much point in accepting even a trivial cost.

During app startup, when no objects of the class have been created, the Main method must be called to begin program execution. Main is sometimes called the app’s entry point. Declaring Main as static allows the execution environment to invoke Main without creating an instance of the class. Method Main is typically declared with the header:
static void Main(){..}
but also can be declared with the header:
static void Main(string[] args){..}
You can declare Main with return type int (instead of void)—this can be useful if an app is executed by another app and needs to return an indication of success or failure to that other app.

The main should be static that it loads first and become your entry point to your program so it's crucial for the main to be static.

C# static garbage collector?

I have a simple class which has a static constructor and a instance constructor. Now when i initialized the class , both static and instance constructor are called. Only static is referred once in a application domain . Can i again call the same class initialization and static constructor initialize again? I have tried but it didn't happen? Is there any way we can call static constructor again in main() method after using garbage collection on the class.
Here is the code:
public class Employee
{
public Employee()
{
Console.WriteLine("Instance constructor called");
}
static Employee()
{
Console.WriteLine("Static constructor called");
}
~Employee()
{
//Dispose();
}
}
Now in main method call:
static void Main(string[] args)
{
Employee emp = new Employee();
Employee emp = new Employee();
}
Output:
Static constructor called
Instance constructor called
Instance constructor called
Now the static didn't called again. Because it is called once in application domain. But is their any way we could call it again without unloading application domain. Can we use GC class over here?
Thanks.
Pal

Unless you prod it with reflection, the static constructor (or more generally, the type initializer) is only executed once per concrete class, per AppDomain.
Note that for generics, using different type arguments you'll get different concrete classes:
public class Foo<T>
{
Foo()
{
Console.WriteLine("T={0}", typeof(T));
}
public static void DummyMethod() {}
}
...
Foo<int>.DummyMethod(); // Executes static constructor first
Foo<string>.DummyMethod(); // Executes static constructor first
Foo<string>.DummyMethod(); // Type is already initialized; no more output

Not possible. The CLR keeps an internal status bit that tracks whether the type initializer was started. It cannot run again. That status bit is indeed stored in the loader heap as part of the AppDomain state. The workaround is simple, just add a static method to the class.

The point of a constructor is to put things into a desired initial valid state.
An instance constructor puts an instance into an initial valid state.
An instance constructor that takes arguments puts an instance into a initial valid state that reflects its arguments.
A static constructor puts the type into an initial valid state. E.g. initialising static members used by the class' static methods or shared by all instances.
Ideally all methods will leave the object and the type in a valid state, but constructors differ in being responsible for getting it into one in the first place.
Any attempt to call a constructor twice is therefore a mistake, since "put it into an initial valid state again" isn't something you can logically do twice ("initial" and "again" don't work well in the same clause). We are helped by the compiler (in it refusing to compile) and the language (in there being no way to express this) from doing such a thing.
And, being a logical impossibility it isn't something you can actually want to do (well, I can want to draw a triangle with more than 3 sides, but only to say that I did). This suggests that you are using your constructor to do something other than setting up an initial valid state.
Doing anything other than establishing such a valid state in a constructor is (as is failing to do so) at best an optimisation, quite often a serious design flaw and quite possibly (worse of all because it goes unfixed longer) an attempted optimisation that is really a serious design flaw.
One sign that your attempt at an optimisation is really a design flaw is a desire to call a static constructor more than once, or to call an instance constructor more than once on the same object.
Identify the desired repeatable behaviour, move it into a separate method, and have it called as needed from both the constructor and elsewhere. Then double check your design's logic, as this is quite a serious mistake to find in a class design and suggests you've got deeper problems.

Is a class instantiated when a static method is called in a non-static class?

Exactly what happens when Foo.SomeCheck() is called in the Bar class? Is an instance of Foo created in order to call SomeCheck()? If so, is this instance stored on the heap, and is it ever collected through garbage collection?
public class Foo() {
public static bool SomeCheck() {
return true;
}
}
public class Bar() {
public void SomeMethod() {
// what happens when we access Foo to call SomeCheck?
if (Foo.SomeCheck()) {
//do something
}
}
}

Static methods differ from instance methods in that no instance of the class they belong to needs to have been created for them to be called. When you call a static method, you in fact make the call using the name of the type rather than an instance of the type - which should reinforce the idea that static methods are not called on instances. That bears repeating and emphasis: No instance of a class is required to call a public static method of that class.
Now, your example is malformed, but presumably, the line: if( Foo.SomeCheck() ) is calling the SomeCheck static method using the name of the type: Foo - not an instance. Bar however, has to be instantiated in order to make this call - however, in your example, you don't have a well-formed instance of Bar. Code generally has to exist inside a method (or a member initializer) - which you don't have here.
To respond to the other parts of your question. Assuming the code in question is part of an instance method, something has to instantiate Bar - and invoke that method. That something would have to create or otherwise acquire an instance of Bar. Reference types will always be creted on the heap - but that's largely irrelevant here.
As for garbage collection, you normally shouldn't worry about this. The .NET runtime makes sure to cleanup instances that are not referenced from any root object in your program. Roots are typically instances that reside somewhere on the callstack or are referenced by static members of one type or another. Since we don't see any code here that creates or references Bar it's impossible to say when it will be collected. For instance, if Bar is a singleton and stored somewhere in a static variable, it may live for a very long time - perhaps the entire lifetime of the program. You can't really know without seeing all of the code that manipulates and manages Bar.

I highly recommend reading the following article:
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects
It explains how the .NET runtime works at a low level, and explains internal nuances like Loader Heaps and how static classes/members work. Technically speaking, there IS an initial instantiation of the 'static instnace' of a classes static members. However, this initiation is handled by the runtime in a different way than it is handled for class instances. Static classes are stored on loader heaps, which are not GC managed. Loader heaps are allocated and grown in a static manner, and are not compacted. The article is a great read, and should give you a thourough understanding of how the CLR operates.
(NOTE: I am not certain of how valid this article is for .NET 4. I do know that there were GC changes in .NET 4, however I am not sure how many fundamental runtime changes there are. The introduction of the DLR and other features may deviate from the explanation in the above article to some degree.)

Foo does not need to be instantiated, neither will it get instantied upon the SomeCheck static method call as per result, you would get the value returned by the method itself, and not an instance of the class.
Please have a look at these references for further details:
Static vs Non-Static Methods;
Static Classes and Static Class Members (C# Programming Guide).
I do hope this helps! =)

It depends on the implementation of SomeMethod. The method will have to be invoked from somewhere, presumably a "driver" class which would instantiate Bar and call SomeMethod. For example:
public class Driver
{
public static void Main()
{
Bar bar = new Bar();
bar.SomeMethod();
}
}
Given your current implementation of SomeMethod, yes, you'd have to instantiate it.
However, as long as SomeMethod only makes a call to another static method, we could make make it static too. In which case you wouldn't have to create an instance of Bar to invoke the method. i.e.
public class Driver
{
public static void Main()
{
Bar.SomeMethod();
}
}

public class Manipulate
{
public static int Main(string[] args) {
Bar bar = new Bar();
bar.BarFoo();
Console.ReadKey();
return 0;
}
}
public class Foo {
public static bool SomeCheck() {
return true;
}
}
public class Bar {
// what happens when we access Foo to call SomeCheck?
public void BarFoo() {
if (Foo.SomeCheck()) {
Console.WriteLine("Hello am true");
}
}
}
Yes you need to create an instance of Bar but not for Foo class since it is a static metod. Only difference is, the static methods are called at class level(compile time) rather than object level(run time), so you don't need to instantiate the Foo class.