I was just curious. I had read a lot about the differences between C# and VB.NET and what you were saying was new to me. Because of the research I did as a result of it, I learned a lot about .NET (no matter the language used), so that was cool. I agree that some of VB's naming syntax is...er...annoying. I haven't bitten the bullet yet to do anything significant in C# yet, but the runtime compiler thing is about to drive me crazy, so it may not be too far off. I look forward to checking out the source in C#...always learn a lot from y'all!

Well, let me give my two cents on the languages...and give you some applause.  I have seen you really grow over the last few years in .NET and in application development as well!  As some may know, it is hard to get a lot of praise out of me at times...but you deserve it.  You are teachable and keep an open mind which is one of the reasons I think that you have done so well.

But on to my two cents   I thought I may as well comment on why we are moving and state of the major reasons and benefits of C# and also point out some of the benefits of VB as well. 

Let me start by saying that I like VB.NET.  It is a good language and there are many things that I really like about it, so this is no means a blasting of VB, but rather a basic explanation of some, not all, of the reasons we have moved over to C#.

1. The design-time compiler is terribly annoying!
   
   If VB.NET would deal with design-time like C# versus constantly running the compiler within the design-time.  If a project gets very large in VB.NET, the design-time environment can't take it many times and requires the solution to be split apart.  We even had to go to the extent of removing project references at this was a major point of failure.  On an average day of development we may be kicked out of Visual Studio 5-7 times a day....way to interuppting for production.
   
2. Compiler error handling in C# is far better than VB.NET
   
   This can be a big one when it comes to reducing bugs before making it into the field.  One of our internal developers most common mistakes in VB was to forget to return a value within a function.  The VB.NET compiler may give a warning...but it will still allow it.  C# will prevent this and while talking returns, it does a better job of ensuring that all code paths have a return value when required.  Another example would be unused variables.  C# does a better job of ensuring that a declared variable is used versus VB.NET.
   
3. C# requires less code as a whole not requiring unnecessary declarative statements
   
   In this example lets take a property declaration.  In VB.NET you have to add the ReadOnly directive in order to make the property only support a get.  In C#, you just leave off a set.  Less code and easier to change later if adding a set.  While on this topic, the whole curly braces controversy generally comes up.  In truth, it really is easier to read the code without all of the extra text.  Instead of requiring End If or End Property, it is just a curly bracket.  This can fall more into opinion, but the code ultimately does look cleaner.
   
4. Inline immediate if testing
   
   Technically in VB.NET you can call Iif(...), but it is an added on method for backward compatability and very inefficient.  In C# this is a very basic inline test that is one I use all of the time.  I had to stay away from inline tests like this in VB.NET due to performance issues...but it really can improve code.  For example:
   
   
   string myVar = myTestValue == 1 ? "First" : "Second";
   
   
5. Yielded returns when returning a collection using the IEnumerator interface
   
   There is no equivelant (that I know of ) in VB.NET.  In C# there is a yield keyword that can really improve performance when enumerating a collection and returning a collection.  This is big, and can be a major improvement in regards to performance in StrataFrame when calling the GetEnumerable() method on a BO.  At present we have to create a collection and return that collection.  Using a yielded return, there is no need to create a unique collection instance for the return.  Here is a good article (http://blog.dmbcllc.com/2009/03/25/advanced-csharp-yield/).
   
6. Code editor is more RAD friendly, especially when creating new instances
   
   OK, this can be a long topic and generate a lot of debate.  But Refactoring code in C# is WAY better than VB.NET...there is not much of an argument here, natively C# is just much better.  Another super awesome feature in C# is the tab after a new statement.  C# will automatically, and always, bring up the correct class including namespace if required of the class instance being created.  For example:
   
   
   MyCompany.MyApp.MyClass class = new (TAB HERE)
   
   
   will produce this without any additional typing:
   
   
   MyCompany.MyApp.MyClass class = new MyCompany.MyApp.MyClass
   
   
   You will still have to put the parens and parms, but it saves a lot of typing.
   
7. Semi-colon terminates a statement versus having to use " _" to go to another line
   
   This doesn't sound like that big of a deal, but it has turned out to be huge for me!  I didn't realize how much additional effort was requiring to do this.  In C#, just go to the next line and keep typing.
   
8. C# doesn't require a minor if test to remain on a single line for abbreviated code
   
   For example, there are a lot of times that I may be doing a single line of code or execution after an if test.  I did this a fair amount in VB.NET but C# does it better.
   
   VB.NET
   
   Dim myReturn As String = "My Value"
   
   If !String.IsNullOrEmpty(myReturn) Then myReturn &= ":"
   
   
   C#
   
   string myReturn = "My Value";
   
   if(!string.IsNullOrEmpty(myReturn))
        myReturn += ":";
   
   
   The nice thing in C# is that you can do it on the same line if you want to.
   
9. C# is the industry standard and the primary language of Microsoft
   
   This is a good reason that C# has a tendency to do more than VB.NET and the editor and RAD tools are better...it gets the most attention.  I am in no way talking negatively about the VB.NET team...they are awesome, but C# lends itself to a little more flexibility for this reason alone.
   
10. Can compile an application to run on other operating systems
    
    This is not a major reason, as I am not insane enough to write for another operating system like Mac....in fact, I was at Best Buy the other day and had to wash my hands after I touched a Mac!   But the point I am making here is that you have more control with the compiler which in and of itself can play benefits downstream....but this is no reason to choose C# over VB.NET.
    
11. Documentation is actually slightly better in C#
    
    C# does a better job with commenting and documentation.  It is also, by default, better about throwing warnings about any public piece of code not commented.
    
12. Easier to tie into the API
    
    In C# there are many times that you can get directly to the API versus having to call a bunch of Declare statements.  Minor, but nice.

I could actually give a number of other examples, but my family is trying to get my attention to head to church!   At any rate, I am sure this thread will grow some more and I will post more examples at a later date, but I thought this might help.

Great post Trent! Much to chew on.



I do have a few comments.







I believe if this was solved, we probably wouldn't be having this conversation. You likely wouldn't have switched and I wouldn't be thinking about it.





You can set these up by project in VB. The defaults for VB are to warn for a number of items (unused local var, no return, etc.), but they can be set to throw a error. Likely this is nicer in C# because it is just setup that way for each project in C#, were as you have to remember to go in and change if for VB projects. I haven't found a place to set defaults for this yet.





I didn't know that the C# version didn't have the performance issues. I've kind of just removed this construct from my brain because it sucked in VB...





I did find one article explaining how to use the yield keyword in VB....but it turned out some bone head had just translated an article about yield in C# to VB without actually seeing if VB supported it. It doesn't. It is on the list of features that VB will support but not sure when (maybe 4.0). (Found that info in a MS bug list for .NET).





This is cool.





In .NET 4.0 for VB, you won't need to use the "_" anymore. Of course, as mentioned, if they don't get the stupid design time compiler fixed, this is a moot feature.





I've read and tend to agree with the thought that you should always use the curly braces, even for single line elements. The potential issue is that some other developer might miss the fact that you've left out the braces and then you'd get something like:







with the developer thinking that anotherVar would only get incremented if myTestVar == 'somevalue', when in fact it would get incremented every time. This is definitely personal preference and I see you point.





OK, that's interesting. Not that I'd ever want to, but how would this work? You write you're own compiler? Modify theirs?





Finally, thanks for the kind words. While I am a curious individual and really, really like to understand things, I wouldn't have progressed nearly so far, as fact, without the help of both the SF team and all the other contributors to this forum! So thanks to all of you!

In truth we would probably still be moving over. Granted, this sealed the deal. The industry standard, especially in the area of development tools, is C# for a number of reasons, many of which not mentioned here just yet. But Microsoft internal teams are very strong proponents of C# over VB.NET. A fair portion of Visual Studio itself is written in C# (the remainder of it is written in C++), but it is geared for tools. Another major reason is that it will actually benefit the framework. If something is going to happen, it generally happens in C# first before VB.NET completely keeps up (some of your other comments elude to this point).







True, but you have to make it instead of exclusive. And to be honest, I have never gotten VB up to the level of C# even when trying. On the flip hand side, I quickly learned how to add warning exclusion tags as part of the compiler commands. I don't have the patience to try and make VB work to this extent for each project, and more importantly, and it is easy to forget and let some things slip few until you remember!







Never been an issue in this shop as the code is generally cleaner and easier to read since we have some hard and fast standards. But I get your point. Just FYI, if you look through Microsoft code you will see that this is a common standard...again, a preference and not a reason to choose one language over another.







Never done it, I just know that you can. Like I said, this is not something that I plan to deal with...soon anyway. I actually am going to mess with getting a C# app to run on Linux, to which there are a number of add-ons and compilers out there for this. I do not plan on moving to Linux, but there could be some long-term applications here, especially in the area of cost and some medical environments that demand certain platforms...so this gives us more long-term flexibility.

So, the next step: suggestions to a developer to move from VB to C#.



Two areas of interest: how to learn C# and how to migrate existing code from VB.NET to C#. I'm more interested in the second item, as I'm pretty familiar with C# (enough to get started), but I have no idea how I'd actually start using it in an existing project.

Well, this is easier said than done. It is my opinion that new development is a good place to start. So new classes, controls, etc. would be created in C# instead of VB. I do not recommend scrapping all of your VB code and starting totally over as that would be painful.



VB.NET is a good language and once it is compiled down, there are very few differences (though there are some). In our medical application, we have been writing all new development in C# for a while now and it grows really fast. We still have more VB.NET code than C#, but it is quickly evening out. Then once the release it 100% out the door, certified, released, etc. then we will start rewriting the base classes in C#.



Here is one thing that is important to keep in mind, it isn't bad to have VB.NET code within your application. For example, if you are moving an application over from Visual FoxPro to .NET...yeah, you would need to kill VFP quick as possible! However, VB.NET code is still .NET and a very powerful language, so it isn't like you are running on an antiquated platform.

Thanks Trent.

OK, so I decided to give C# a little test drive. I have a little research project I'm working on and I thought I'd just whip up a C# version.



Now the language isn't to hard, I'm picking that right up. However, I'm about to start drinking over how the editor is handling formatting.



In VB, when I type, I don't really even think about things like indenting, it just happens. When I type, it just puts where I want. So, If I type:







I get...





When I do something similar in C#...





I get...





and not...





* This is with Enable Virtual Space checked



Also, when I use code snippets, it doesn't fix the indentation! Which means I have to highlight the code and manually manage this. Very frustrating.



I've also read about how you can use Ctl K, Ctl D or Ctl K, Ctl F to format something...I'm not sure because neither do a damned thing.



So, what sort of settings might I use to enable the sort of smart formatting I'm used to with VB? I'm not really interested in having to type every single character exactly like I want it to appear. I'm building apps here, not ASCII art!

The editor is actually far better once you get used to it and get it setup.  I might recommend getting CodeRush from DevExpress.  It is horriblly irritating with VB.NET, but works very well with C#.  You can make the text editor look a lot better, change how regions looks, colors, etc.  And it makes moving to C# a lot easier.  You will have to turn off a lot of irritating junk that is enabled by default, like templates...they REALLY annoyed me.  But once you get it setup and configured to your liking, it is much better.

But before you haul off and get that, the settings you are talking about are standard .NET options.  Click on Tools -> Options and go to the Text Editor options for C#.

All of the frustrations you mentioned can be fixed here.  You might add a frustration or two while figuring it out also

LOL...the Ctrl K+D is something I use a lot...a whole lot.  The ONLY reason it will not work is if there is an error within the syntax...or you have your formatting setup to do just what you mentioned. 

I am not generally a big fan of too many tools, but CodeRush from DevExpress is really a nice Add-In for VS and makes formatting code, snippets, etc. really nice.  You can move methods around between regions, change declaration types, etc. with inline editor tools (if turned on) through this add-on.  Check it out, it really is nice for C#.  I will tell you this, however, if you leave it on for VB.NET....well...prepare for a few cuss words to pop out of your mouth.

I've done some more test driving, this time on another machine. All the weird stuff I previously posed about isn't happening here. So, I must have something weird setup on the first machine. In any case....



I'm liking it!



My brain still wants to put types after the variable when declaring them and I'm kind of bummed you can't declare/initialize in one step:











But mostly I'm liking it. Amazing how much some IDE niceties were causing pain (when it wasn't indenting correctly on first machine, especially when using code snippets).



I really like how constructors are handled, were you can identify other constructors to run:











I also found a cool site that compares VB to C# side by side. Very quick way to look up how to do something in the "other" language.



http://www.harding.edu/fmccown/vbnet_csharp_comparison.html



Thanks for the info and encouragement! I'm looking forward to the new 1.7 release and to doing more in C#!