using private static Main...

[Tony Johansson]

Hello!

I'm used to having the access modifier set to public on Main but it works
with private too.

So because of the above must CLR be considered as being a class member.

I think it would be more correct to give compile error if Main have access
modifier set to private. Do you agree?

//Tony

 

[Jon Skeet [C# MVP]]

I'm used to having the access modifier set to public on Main but it works
with private too.

So because of the above must CLR be considered as being a class member.

I don't understand the previous sentence - could you reword it?

I think it would be more correct to give compile error if Main have access
modifier set to private. Do you agree?

No, I don't. It's useful being able to make it private - it prevents it
from being called (directly, other than by reflection) from other
managed code.

The CLR is a special case - it's not calling Main in the normal way
from other managed code, it's calling it as the entry point to the
application. I think it's fine for it to be able to see and call a
private Main method.

 

[Arne Vajhøj]

I'm used to having the access modifier set to public on Main but it works
with private too.

So because of the above must CLR be considered as being a class member.

I think it would be more correct to give compile error if Main have access
modifier set to private. Do you agree?

CLR calling Main is a special case.

I agree from a puristic point of view and always make my
own Main public.

But whoever designed this at MS did not agree and it will
never be changed (because it would break old code).

You can make it part of your coding convention to always
make it public.

Arne

 

[Arne Vajhøj]

I don't understand the previous sentence - could you reword it?

Only class members can access private members.

So CLR being able to access private Main gives it the sames
privs as class members.

That is from a interface point of view - from a practical point
of view, then the CLR must have lots of other privs as well
compared to code running inside it.

No, I don't. It's useful being able to make it private - it prevents it
from being called (directly, other than by reflection) from other
managed code.

In the few cases where that would be an issue, then I don't think
reflection being a requirement would mean much of a difference.

Arne

 

[Jon Skeet [C# MVP]]

Only class members can access private members.

So CLR being able to access private Main gives it the sames
privs as class members.

That is from a interface point of view - from a practical point
of view, then the CLR must have lots of other privs as well
compared to code running inside it.
Exactly.


In the few cases where that would be an issue, then I don't think
reflection being a requirement would mean much of a difference.

I just think it's tidier to not expose to the outside world methods
which are designed to be entry points. Typically entry points do things
(such as settings theming etc) which are inappropriate to do from
elsewhere in a program.

 

[Arne Vajhøj]

I just think it's tidier to not expose to the outside world methods
which are designed to be entry points. Typically entry points do things
(such as settings theming etc) which are inappropriate to do from
elsewhere in a program.

AFAIK then you can not even set a ref to an exe in VS.

If it is a NAnt build, then I would assume the developer
has a decent understanding of what he/she is doing.

But since VS wizards generate private Main then it seems
as if MS agres with you (they don't generate explicit
private keyword though, which I absolutely not like but ...).

Arne

 

[Jon Skeet [C# MVP]]

AFAIK then you can not even set a ref to an exe in VS.

Yes you can. You couldn't in VS2003.

But even within the exe, you probably don't want to accidentally do it.
Better to not expose it in the first place.

If it is a NAnt build, then I would assume the developer
has a decent understanding of what he/she is doing.

But since VS wizards generate private Main then it seems
as if MS agres with you (they don't generate explicit
private keyword though, which I absolutely not like but ...).

I tend to not specify private explicitly myself, but that's a whole
different debate...

 

[Richard Blewett]

CLR calling Main is a special case.

I agree from a puristic point of view and always make my
own Main public.

But whoever designed this at MS did not agree and it will
never be changed (because it would break old code).

I think I'm missing something. How would it break old code? We're talking
about the wizard generated code here that gets generated once when you
create the project. They would not be changing the meaning of private.
Although I still think it should be private as its a special method for the
CLR to execute not a general purpose method for other types to execute.

You can make it part of your coding convention to always
make it public.

Or you could add your own project type or modify the template code they use
to create the project

Regards

Richard Blewett
DevelopMentor
http://www.dotnetconsult.co.uk/weblog2

 

[Arne Vajhøj]

I think I'm missing something. How would it break old code? We're
talking about the wizard generated code here that gets generated once
when you create the project. They would not be changing the meaning of
private.

If the next CLR would not run private Main's, then a few
hundred thousand or millions of programs would not work
any more.

Arne