I have been long time without blogging, and the reason is that I have been quite busy doing the following:
- I have migrated the whole code of my MZ-Tools 7.0 add-in from VB.NET to C#. After 10 years programming in VB.NET, I decided to switch to C# and the best way is to use it everyday, so I had to migrate the product. The migration was successful and build 188.8.131.52 released on December 1 was C#-based. Only a couple of bugs were introduced that were not detected by the automated integration tests. FWIW, I used Instant C# from Tangible Software Solutions.
- I have enforced the Code Analysis feature of Visual Studio on the MZ-Tools code base with All Microsoft Rules, and after lots of fixes I was able to pass all with some custom suppressions and four of them disabled: CA1031 Do not catch general exception types, CA1502 Avoid excessive complexity, CA1506 Avoid excessive class coupling and CA5122 P/Invoke declarations should not be safe-critical. If you have tried to enforce them on a large code base you know how time-consuming is that.
- I have done massive architectural changes in the code base of MZ-Tools for Visual Studio to prepare a new unified version 8.0, .NET-based, that will support Visual Studio (VB.NET, C#), Visual Basic 6.0 (“Classic”), VBA editor of Office 32-bit and VBA editor of Office 64-bit. That means to encapsulate the automation models of VS and VB “classic”. I already have the user interface, options, setup and unit-test/integration-test subsystems. It “only” remains the features, but it will take me months yet :-). I will blog about this in the next months when I am closer to the release.
- I have created an integration test runner that runs in the IDE where MZ-Tools is loaded, rather than in the IDE where the MZ-Tools source code project is loaded. While the Visual Studio SDK provides a remote MS-Test-based host adapter for this purpose, I tried it two years ago with disappointing results, so I created my own integration testing infrastructure in MZ-Tools. But the MZ-Tools add-in, its integration tests and the test-runner were in the same assembly (using a special configuration). Now I have isolated them so I have the add-in, the integration tests and the test-runner in three separate assemblies. I hope to release the test runner in CodePlex or similar some day.
- I migrated to Visual Studio 2012 (I am almost used to the new UI style) and I am planning to adopt TFS (I am finishing the simultaneous reading of Professional Team Foundation Server 2012 and Testing for Continuous Delivery with Visual Studio 2012). In the past I used Perforce, but after a failed restore after a crash (likely my fault) I didn’t use source control for some time and I want to adopt TFS now.
And I was almost three weeks on vacation during Christmas, resting and watching lots of TV series