The curse of updating the IDE
Many of these MDA events were about reference counting for COM objects (ReportAvOnComRelease) – that is, keeping track of how many pointers you have to some external object such as a Word document – so that the .NET Framework’s garbage collector can tidy them up.
When the number of pointers you have to an object falls to zero the object itself can be deleted, but the Garbage Collector won’t tidy up right there and then, to avoid slowing your application down. Garbage collections happen only sporadically, whenever there’s a shortage of memory or your application specifically requests one.
It appears that while VS2008 and .NET 3 were quite forgiving in this respect, VS2010 and .NET 4 are far more fragile. The COM errors weren’t being ignored in all cases, and we had to recode, rework and even replace some components.
Our application’s integration with Office has always been “interesting”, because the customer runs mixed versions of Office, with some workstations using Office XP and others using 2003, but they all use Outlook 2003.
To be ready for when they decide to upgrade, we’d built the application using the Primary Interop Assemblies (PIA) for Office 2007, and thoroughly tested all its functions for backward compatibility with Office 2003 and XP.
If we’d tried to target Office 2003 or XP, we’d have had a hard time maintaining compatibility through three versions of Office. Our development machines now run Office 2010 (both 32- and 64-bit) and the Office 2007 PIAs work fine with those versions, too, for the range of functions we need in this application, giving compatibility across four versions of Office.
One particular area we had difficulties with was mail merge. We couldn’t make automation of Word’s mail merge functions work in Office XP using the Office 2007 PIAs because the mail merge properties, methods and events in Word 2002 (XP) were too different.
Microsoft Team Foundation Server
MSF Agile 5 Process Guidance
TFS 2010 Power Tools
VS 2010 Power Tool
Luckily, that functionality was required only by one department, so an easy workaround was to make sure those few people used Office 2003. The alternative, detecting which Office version is installed and treating Word 2002 differently, would have added considerably to both our development and testing effort.
When the customer does upgrade to Office 2010, our existing application will work without modification and we can then switch to developing it against the Office 2010 PIAs as part of our normal maintenance cycle, which will future-proof the application as far as possible and make eventually upgrading to Office “15” less painful.
After two weeks of acceptance testing with the new .NET 4 version of the application in a test environment, the customer was happy to roll it out to all staff, which we did over a weekend, ensuring that each workstation first got .NET Framework 4, and then our new code.
Come Monday morning, we found that most people had no problems, but a few were experiencing intermittent crashes or other errors, usually affecting the application’s drag-and-drop integration with Outlook.