>>The worst disappointment was the Office automation. Not because it's inconsistent, memory hungry, slow or clumsy (it is all of that), it's that it's a house on sand. Whatever you do may not work with the next version. I have VFP code, parts of which were written in 1989, which still works. Most of the automation code had to be reworked over and over, because of this particular type of software rot.
>
>Not sure why that would be. Whatever you do in FoxPro you can also do with .NET and the `dynamic` type. I think if you use the actual strongly typed automation libraries, they are scoped to a very particular version of the SDK which in turn is usually scoped to a specific version of Office.
>
>But you can dynamically create COM objects, and use `dynamic` in the same way we do it in FoxPro and not be dependent on specific versions. Same COM instantiation and same late COM binding.
>
>IOW COM is COM - doesnt' matter where you use it from.

This paragraph was specifically about Office automation. With every new version there would be some feature deprecated, or some brand new dialog which still showed up even though the general setting to suppress them was set. Probably the setting isn't respected at class level (do they use classes at all? :), they don't have a rule, they have a list - so the latest additions don't get on the list.

Also, some nice features can't be automated any more because they were abused, or at least shutting them off was the easiest thing to do to show how they care about security. So what you did last year to impress your customers was suddenly forbidden.

For the rest of the COM world, which respects M$'s guidelines, I agree with what you wrote here, it is so.