>>Unfortunately your scenario is not uncommon at all. I've seen a lot of this recently and frankly this is the worst kind of FUDD you can throw at a development situation.
>>
>
>I've heard this several times now, so I wondered if .NET is intended to replace COM completely for the developer. I can see it possibly replacing COM for ActiveX, multi-language projects, and Web Services. Is there a mechanism in .NET to replace COM for Automation? Also, if you want to split up processes among several computers on the server side, wouldn't COM+ be a better choice? Or should we expect that all components will "evolve" to Web Services? Personally, I don't think I would want to expose everything, and I could probably do without the extra overhead of Web Services and IIS where they are not needed. What's your take on this?

COM and automation are the same thing... Automation is just a special interface (IDispatch). I think Microsoft is working hard to expose all the COM interfaces that were exposed via IDispatch via the .NET framework. Things like Office DMO surely will be accessible through .Net in the future, but not right now.

Breaking up processes: .Net will handle that and Web Services is one way that you can accomplish that and it will be more stable than the current DCOM based mechanisms that are used which are quite frankly - crap. Today distributed COM+ works only with hideous configuration and security issues and Web Services promise a much easier path to distributed computing even if there's more overhead and slower performance. But if properly designed additional overhead may not be as excessive as you think. As far as exposing goes - no different that DCOM. If you hide the Web Services properly then there's really not much threat of unwanted interference. Plus there will be security support in the next version of SOAP (which probably won't make the initial relase of .NET though).

+++ Rick ---