jcarlisle, I'm not saying that COM in the background is bad from a performance (unless it was a problem with the COM implementation) or productivity standpoint. Just that there are some things that really keep me up all night digging around the framework, and are exciting, while other aspects that are just wrapping old COM functionality do the opposite. It's more as you say, that I feel I have been *sniff, sniff* misled. Where it really comes in to play is when we are deciding whether something should implement something in .Net or J2EE. Naturally the Windows folk say .Net while the Java guys say J2EE. And really the deciding factor is always performance, and stability followed manageability. This is when we (the .Net folk) start quoting things we get from MS about those topics. Let me tell you, it's hasn't been good when we win an argument with "but it's different now" or "it works better or easier now" then have to come back and say "well, underneath, it's still the same old thing. It's just that the semantics are different on the surface, becuase performance and stability do not come from easyier development or better productivity during the coding cycle. It's what's under the hood that matters.