The following editorial will have little or nothing to do with the content of this issue. Admittedly, it will be about development and, in fact, it will be about development using .NET. However, I will leave it to Patrick Hynds, this issue's Guest Editor, to focus your attention on security - which is the primary topic of this issue. For further information on this, please see his Guest Editorial.

I would like to take this opportunity to provide you with yet another case study in what I like to call "COM Wrapper Insanity." This is a phenomenon whereby one attempts to use technology provided by Microsoft, believing it to be pure managed code, only to find that it is, in fact, just a series of COM wrappers, in various states of repair.

I have mentioned this in the past in reference to the System.Management and System.DirectoryServices namespaces. Unfortunately, I quickly found that I was largely alone in spending 99% of my time coding with these namespaces. Therefore, few people were able to relate to my pain.

A few weeks ago, I began working with Visual Studio Tools for Office 2003, building some advanced spreadsheet functionality for Excel 2003. I quickly encountered similar pains, but it occurred to me that many more of you might be able to relate to this situation, since Office is, by far, the most popular desktop productivity tool on the planet.

My struggles began as I tried to find out how to include .NET in my Excel spreadsheet. I was disappointed to see that the only documentation actually in Excel itself for programmability was still for COM-era VBA. I was further disappointed to find that the mechanism for including my code consisted of just adding a couple of custom properties to the workbook - which yields no deep integration, or even any way to easily browse for my assemblies.

Once I realized that the objects were only documented in their VBA COM-era form, I was ready to proceed and found that the COM wrappers in VSTO 2003 were generally well named and intuitive. My next bit of trouble came when I wanted to iterate through a collection of objects. Since I'm a C# coder, of course I figured that I would use the foreach nomenclature provided for this purpose. However, since the collection in question was not a true .NET collection, but merely a COM wrapper itself, this call failed.

The result of this was that I had to implement a for-next loop that counted the number of items and iterated through them by position in the array. Unfortunately for my purposes, I was deleting some items from the array as I progressed. The end result was an irritating bug in my code that would never have materialized if I had been able to use the normal .NET foreach construction.

My final gripe - for the moment - is that exceptions are completely swallowed by Excel 2003. I don't know whether this is a function of its COM origins or not, but I can tell you that I had an insanely hard time troubleshooting some bugs until I realized this.

The good news is that VSTO 2005 is on its way, and I have been promised that it will be much better and less COM. Here's hoping!