Moving from VB.Net to C#
[There's some interesting threading stuff further down if you want to skip the first couple of paragraphs about my C# preference]
At the end of last year, we officially switched to all new development in C# instead of VB.Net (to the cheers of many of us on the team who are quite experienced with C#).
We converted some code to C#. We found the C# code executes faster and is more compact. While I'm not that crazy about VB.Net, it's usable and you can do some real stuff in it (I never did like VB6). What I really admire, though, is the VB.Net compiler.
When converting to C#, we realized what amazing things the VB.Net compiler does--and what garbage code existed in some places in our system. The VB.Net compiler is very forgiving and takes what you give it and figures out what's really needed under the hood. Pretty cool stuff, but it does add overhead to your code.
Threading IssuesWe ran into a real interesting gotcha recently that had to do with threading. We have a VB.Net console application. When it ran, it was causing all sorts of memory problems. The production application actually threw out of memory exceptions. It was driving us nuts. This application doesn't use that much memory. It does run in a loop.
Occasionally when in the debugger, we'd get some interesting COM exceptions complaining about a Context Switch Deadlock. I've seen this before and was kind of surprised, since the app I was debugging was 100% managed code.
Someone on the team tracked down this article:
http://msdn2.microsoft.com/en-us/library/ms172233.aspxIt's quite interesting. Microsoft by default assumes that a VB.Net console application should run as an STA. Our console application was multithreaded. However, it wasn't really running this way because under the hood, VB.Net adds a STAThreadAttribute to your console application. This is more of Microsoft VB's "hide programming from the programmer" attitude that I don't like. Why on earth should it default a .Net managed application to STA just because it's in VB?
The solution to our problem was to add the MTAThreadAttribute to our application and all ran well. No more memory problems.
Because it was STA, the message pump wasn't running. That meant that the garbage collector wasn't able to free some things. I'm glad it's fixed now. I just wish that Microsoft would not hide such details. Even if there is a good reason for VB.Net console applications to default to STA, put the attribute in the code where we can see it; don't just have the compiler insert it.
