views:

141

answers:

3

I downloaded a zip of source files containing a C# project with multiple entry points / Main methods. Since I wanted to tinker around, I created another one like this in a new type/class

class MyExperiments
   {
      static void Main(String[] args)
      {
         // do something
      }
   }

then I switched to project properties. Simply switch the startup object to MyExperiments eh? To my surprise, the dropdown didn't have it. I rebuilt, made the method public, tried a whole lot of stuff.. but to no avail. Finally I edited the .csproj manually in notepad and then it worked. More tinkering around, I removed the parameters to make it

static void Main()

and now VS Project properties could 'see' the startup object. So now I could select it using the dropdown. I then added the String[] back and everything still worked.

Seems a bit weird to me (because the most common form is a Main method with parameters for command line args from the C/C++ times). MSDN says the dropdown will contain valid startup objects if they exist in your project.

+6  A: 

Good thing you copy-pasted it, it is the capital 'S' in Main(String[] args). Apparently VS uses some text matching, and it's case sensitive. As it probably should be.

Henk Holterman
guess that will show those "Know your CLR Types" people like Jeff Richter n Jon S. :) Does anyone know where this can be filed.. very annoying when you're trying to stay motivated at the end of your day job and learn something.
Gishu
It has been discussed on SO many times and I think the consensus is to use string and not [System.]String, like int instead of Int32
Henk Holterman
"As it probably should be." - not convinced by that; it makes no difference to the compiler, so why should the IDE care?
Marc Gravell
@Marc: You may be right but getting it totally correct would require Reflection. I was thinking along the lines of RegExing the code, looks like that's what it's doing now. And then a limited set of patterns is better (safer). No messing with MyNamespace.String etc.
Henk Holterman
Accepted.. although I too don't agree with the last line. both string and String should be treated identically IMO
Gishu
+5  A: 

lol - it looks like a bug in the IDE:

static void Main(String[] args) {}

doesn't show, but

static void Main(string[] args) {}

does!

Marc Gravell
WTH? Drove me crazy for around 10-20 minutes atleast.
Gishu
Probably not a bug, but rather that it's limited to use the C# keyword for the string type, just like you can use int as type for an enum but not Int32. You can declare your own String class, but you can't tamper with the string keyword.
Guffa
Thanks. Filed https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=469203
Gishu
Guffa: The general api guideline is to use the names of the actual CLR types and not the language-added aliases. e.g. ReadInt32() is better than ReadInt()
Gishu
@Gisha - that only applies when naming **members**. When dealing with parameters, variables, fields etc - the language type is generally preferred.
Marc Gravell
Hmmm.. now you've made me curious. Can you give me an example or link demoing this? - I had the opinion that the parameter, var, fields should not have the type info in their names. e.g. bugCount
Gishu
@Gishu: bugCount is different form ReadInt32 which is part of a series like ReadChar, ReadDouble etc. I gather that ReadSingle would be preferred over ReadFloat
Henk Holterman
My understanding is the same as Henk's - but parameter types are not part of the name, so "void Foo(float x)" is (IMO) clearer than "void Foo(Single x)" - but if the type was important in the member name, use Single
Marc Gravell
A: 

Update: Response to the Connect Feedback / bug,

Thanks for the feedback! It looks the issue here is that the "String" parameter in the Main method needs to be a fully lowercase "string" (and it seems to have been pointed out on your stackoverflow post). I see a suggestion here to update the project property page to be slightly smarter about picking up the startup object, but given that there's a reasonable workaround, we're going to invest our resources in stabilizing and improving performance of VS2010. I'm going to go ahead and resolve the bug as a "Wont Fix" but please feel free to re-activate the bug if you have any further questions/comments.

Thanks, DJ Park C# IDE, Program Manager

So seems to be something you'd have to keep at the back of your mind for now - Gishu

Gishu