Mark Shields: "A compiler writer's guide to C#". A complete yet amazingly terse 89 pages covering the entire C# language. [Peter Drayton's Radio Weblog]

Wow, that's good stuff™.

I, too, believe that the COM Interop is broken because it doesn't leverage IDisposable. I have to think this is one hand not knowing what the other hand is doing, given that IDisposable was really only put it because of the intense pressure by the .NET Beta community (mostly Chris Sells).

I wonder how much effort it would be to have someone else make a new COM interop tool that could grok a typelibrary, and generate the same goo, but with IDisposable tacked in for good measure. Has anybody approached this? [The .NET Guy]

Brad is in the same boat with Sam, but... I think I'm in there too. ;) The only difference that I see between their point of view and mine is that I don't consider it "broken", beause there is a way to deterministically scope the lifetime of the COM object reference (i.e. use Marshal::ReleaseComObject).  In the end you will always need to do some extra work in your component to make sure that the reference is cleaned up, regardless of whether or not they implement IDisposable::Dispose. It's just a matter of what you need to type. C# is the only language that has special semantics for IDisposable (i.e. the using statement) which is definitely nice, but what about other languages? Take VB.NET for example, those developers will still have to type out the Try/Finally and at that point the only difference is what they type in the finally block: Marshal.ReleaseComObject(myComVariable) OR myComVariable.Dispose(). Now that's not to say that VB.NET and other language won't eventually gain a shorthand statement for the IDisposable pattern like C#'s "using", but it's not there today in any other CLR based language that I'm aware of.

So to sum up, the only point I'm trying to make is regardless of the semantics of releasing the underlying COM object reference, you will always need to do some extra thinking/typing in your program to make sure the reference gets released exactly when you want it to.

I've posted a response to Sam's "Is Com Interop Fundamentally Flawed?" article. Hopefully this provides a unique look at the problem that not many other developers have supplied.

This results in a response message containing the value 5, a result which isn't valid according to the schema generated for the WSDL. Perhaps it should generate an array of values ? [Simon Fell]

As Simon already found out, applying the FlagsAttribute fixes the problem, but I also had somewhat of an Enum revalation while discussing it with him. Here was my latest response to Simon on the subject:

Forget about the SOAP serialization for a second, but this actually seems more like a CLR problem to me. The runtime allowed the value 5 to be stored in a fooEnum value type. Heck, I just changed the method to do this:

return (fooEnum)5;

and it worked too. Looks like the testing the integral value upon cast for validity within the Enum is not there. So in the end I suppose they could add extra checks at the serialization layer, but it looks like the CLR is at fault for even allowing this assignment to take place. Then again, enums are just an abstract concept intended for compile time type checking. So if you do naughty things like this, maybe the compiler ought to be warning you?