>Here is where we disagree. There is a difference between an app scaling and an app that needs to be replaced. Just because an app does not scale, does not mean the app was incorrectly architected.

If the remote possibility for the need to scale was present in the original spec, then it was incorrectly architected.

>Because COM doesn't work well over the Web and XML does. Because COM has registration and DLL Hell issues. Because COM can't interoperate well with other systems. Because if you sell data over the Web and I want that data, I can't rely on COM. How do I know your system is built with COM? How am I going to get a COM object through the firewall?
>>
>
>I am so tired of this argument. COM implemented the right way does work.

Huh? How do you implement com through a firewall? I'm not talking about punching holes, I am talking about port 80/443? Without writing a lot of code on both the client and the server side, you can't.

> Prudent testing and having standards gets around a lot of the DLL Hell issues.

Translates nicely into 'a lot of extra work' gets around the DLL hell issues. THe fact that you know how to work through a COM versioning issue has nothing to do with the fact that the problem is commonplace, and is a PITA even for those that know exactly how to solve it.

>Somehow, folks are building web apps that get through firewalls today?

Yeah, they're writing their own code to do it. Have you ever written one of these apps? It's not trivial. (It's getting easier and easier now that I have my own framework to deal with it, but nonetheless, my framework has a lot of code).

>With all that said, I think there are some intriging aspects of .Net from a technical perspective. However, I am going to wait and see how it all shakes out..

We all are. But I'm going to play with it ahead of time out of professional curiosity.