Over the past month we’ve been busy updating our development environment, which has been an interesting experience – interesting in the sense of the Chinese curse (“May you live in interesting times”).
It has, however, also brought us a few new tools we can use to streamline development. We started out on a prototype application that we were building for a customer, and built it entirely using the new Visual Studio 2010 with Windows Forms and the .NET Framework 4.
While we also looked at Windows Presentation Foundation (WPF), we’re still not confident in our ability to use it for large projects, because the range of controls it makes available is still limited compared to Windows Forms.
The WPF framework is very powerful and code compiled from it can run faster than Windows Forms, but if you double your development time by having to roll your own controls rather than buying what you need off the shelf, then it’s of dubious value to us.
If you double your development time by having to roll your own controls rather than buying what you need off the shelf, then it’s of dubious value
Programmers also need some learning time to get used to WPF, which has distinctly different properties, methods and events to those used in Windows Forms, and it’s only with the arrival of VS2010 that it’s finally gained drag-and-drop data binding (previous versions made you laboriously handcraft XAML code to bind data sources).
After a successful prototype with VS2010 and .NET Framework 4, we tested upgrading a large application – about 500,000 lines of code – to the same platform. This application uses SQL Server 2008 to store its data and integrates with Microsoft Office (Word, Excel and Outlook) as well as employing many third-party controls to view images, PDF files and scans.
When testing the converted application, we found its main codebase to be at least as stable as on our previous platform (VS2008 SP1 + .NET Framework 3), but the interfaces to external components, particularly COM components such as Office or ActiveX controls, were distinctly flaky.
Everything ran fine in debug mode inside the IDE (integrated development environment), but once deployed into a test environment the application often fell over with the error message: “The application has encountered a problem and has to close. We’re sorry for the inconvenience. Would you like to report the problem to Microsoft?”
Unexpected crash
Our application wasn’t generating any exception that we could trap and report, but was crashing in places that had previously worked just fine.
As the programmers weren’t seeing any problems within the IDE, we decided these must be hidden, so we turned up the error reporting level – Visual Studio permits you to decide which exceptions and errors will cause your code to break in debugging mode, and which will be ignored to be handled by your own code (Debug | Exceptions…).
We told it to break on all exceptions and turned on all the Managed Debugging Assistants (MDAs), and that proved to be a revelation. These assistants generate information messages about runtime events that you can’t otherwise trap, and you can use them to isolate hard to find application bugs that occur in the transitions between managed and unmanaged code.
The errors picked up by MDAs are usually ignored by the Common Language Runtime (CLR) while the application is running, as otherwise they’d stop your application dead. We found that our code was generating many MDA events, particularly when it dealt with COM components, and even relatively simple code to send email using the System.Mail namespace was failing.
Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.
