C# 4.0 and Visual Studio 2010

I've started looking into C# 4.0, Microsoft .NET framework 4.0, and Visual Studio 2010, hoping there will be some cool new features that I will like. I've done very little with some of the new features of .NET 3.0 and 3.5, and didn't notice much new with Visual Studio 2008. Here are some of the things I've seen that look intersting:

1. Parallel Extensions for the .NET Framework: Now that most computers have 2-4 processors it is become more apparent that parallel programming will be going mainstream. Instead of being relegated to high end scientific and business applications on large supercomputers and distributed systems, every day programmers are going to need to know and use techniques for parallel programming. These extensions look like they are a step in the right direction. When combined with solid software development practices, these can get a developer headed in the right direction to be able to easily take advantage of the multiple cores available in computers today.
2. C# optional parameters: One thing that I do miss from C++ is finally making it's way to C#. I can't count the number of times that I have had to create multiple different variations of a function, just to be able to mimic the capabilities of optional parameters. What could be 3 or 4 functions with slight variations in parameters, can now become a single method definition. Easier to maintain, easier to use, and much more convienenient. Plus by allowing named arguments, you don't even need to specify all parameters from left to right, you can pick and choose which parameters you want to set, when yo call the function.
   
3. Static ID's for ASP .NET controls: I've always wondered why Microsoft decided to enforce their control naming on all ASP .NET developers. I could understand if the naming standard was the default, because it does enforce that all of the names are unique, but we are finally getting a way to specify the name we want. This will make my like so much easier, especially for JavaScript code and forms post-back. With multiple nested master pages and containers, the length and complexity of names for controls is ridiculous. I've actually had a few cases in JavaScript that I've had to create a lookup variable to map my usable names to the actual control names.
4. Dynamic Programming and Dynamic Variables: I have to admit that I haven't done anything with the dynamic languages and features that already exist in .NET, and I don't intend to start now. I tend to prefer the enforced structure and design of normal development, but it is nice to know it is available if I want to give it a try.

These are just a few of the features that I've seen that look interesting, once I've have a chance to play around with it more, I'll try to come up with some more exciting features that we can all look forward to.

Visual Studio vs. NUnit unit tests

I've used NUnit over the last few years at a few jobs to do unit testing in C# code. At my current job we started trying to use the unit test features of Visual Studio 2008. We had been using NUnit but we needed a solution that would work with our new C# code, as well as testing our existing legacy C++ code. The C++ code we have is primarily unmanaged cross platform code that is used in both Windows and Linux applications.

Everything we had read indicated that the Visual Studio unit testing didn't work very well with unmanaged code. At first this seemed true, but we have been able to work around this well enough by just simply setting project settings to allow executing mixed mode code.

One of the biggest issues has been trying to debug into unit tests that are throwing exceptions. Because the unit tests are managed code, and most of the code being tested is unmanged, almost all of the exceptions come across as SEHExceptions. This can make it more difficult to determine what is going on, but can be overcome by going to Debug->Exceptions and checking some of the exceptions to break the code when the exceptions are thrown.

Other than that, the biggest concerns I've had with the Visual Studio unit test system is that they seem to have been over-engineered (Microsoft would never do that, right?). Pretty much everything seems to have been copied from NUnit, except it is harder to use. Just trying to determine how to run a specific test or tests is a pain. NUnit is just very simple and easy to use.

So far everything is working OK, and at least we have one solution that works for both C# and unmanaged c++ unit tests, but I still miss the ease and simplicity of NUnit.

[Update: 2/6/2009]
We decided to use Visual Studio unit test for C++, but after more debate decided that NUnit is a far superior solution. It just works and it works well. Visual Studio works, but not as well and not as easily.

Stack unrolling for exceptions in managed/unmanaged C++ code

Trying to mix managed and unmanged C++ is not pleasant. At my current job we have been re-architecting some of our core business logic. One of the focuses has been to make sure the code is set up to behave well with our MySQL database using transactions.

To facilitate this we have set up an object to help manage and maintain the transactions. If the code throws an exception, the transaction object automatically gets destructed as the stack unrolls, causing a rollback. This had been tested and was working great in our unmanaged code.

One of the GUI applications we maintain runs in managed C++ mode, but still uses our underlying unmanaged C++ business logic. While testing this application we found that when the business logic would throw an exception, the code was not properly rolling back transactions in the database. After hours and hours of debugging and research we determined that the Microsoft compiler doesn't seem to unroll the stack properly when crossing the managed/unmanged code boundary. We found posts indicating other bugs with this across this boundary, some of which had been fixed in Visual Studio. The only way we were able to get the code to behave properly, was to wrap every function that uses database transactions and is called directly from the managed code in a try-catch block, that just rethrows the exception. Like this:

void DatabaseTransactionFunction()
{
try
{
TransactionHelper t();
t.Start();
//Code that may throw an exception
t.Commit();
}
catch (std::exception&)
{
//This forces the destructor on t to be called
//which rolls back the database transaction.
throw;
}
}

This is the only way the code would work. Seems unnecessary, and the code works fine if it is called by unmanaged code. So that seems to leave something with the Visual Studio compiler. Everything I've seen and read indicates that the compiler should behave like we think, The destructor on object t should be called when an exception is thrown, which would roll back the database transaction.

I would make the argument that Microsoft should fix these things, but all of the other issues I've seen with using managed and unmanged c++ code together would just make me recommend avoiding it. Use C++ for unmanged applications and stick with C# for unmanged code, and don;t mix them.