>>I don't see .Net applications limited to just consuming/creating web services. How about traditional windows applications, independent of the Web? .Net can create those too.
>
>Unfortunately, comparitively little effort has gone into this to make .Net a killer desktop application platform too. There are many problems that become apparent once you start working with the tools and build even simple applications. Performance being the biggest one of it followed by the lack of some very important tools that must still be consumed via COM (like a Web Browser control just for my most high profile example). Then there's the whole security and versioning model that IMHO will be just as bad if not worse than the DLL hell we have now. It'll be a Microsoft controlled DLL hell, too, which if history is any guideline could be very scary. One example, is code that was written with one version of hte CLR will not run unless that very particular version of the CLR is installed. Which means your (standalone) apps require a very specific version of the CLR to be installed (read *large* distribution). Unless Microsoft can actually keep a version of software around long enough
>to get it stable between SPs, fixes and interim security fixes it will be potentially difficult to distribute and install applications especially if they are downloaded from the Web.
>

Rick, I think you've focused in narrowly on the hype behind the ease of deployment issues for CLR applications; you .Net apps will be as sensitive to variants in the CLR as current deployments are to traditional versioning issues. What we're going to see IMO is an associated bloat in deployment size in the managed code arena, which will end up with multiple CLR engines being needed to reside on a single station, to be managed in a fashion reminiscent of the side-by-side COM and DLL version supported starting with Win2K. The encouragement of .Net developers to deploy with explicit reliance on tools like the Windows Installer technology will end up requiring the incorproation of that technology at the lowest levels of managed code implementation behind the scenes. In order to gain aceptable performance, greater burdens will end up being placed on execution platforms at all tiers, as each tier will require potentially multiple CLR engine sets, with slightly different versions of the .Net namespaces supported by each. Thank god the cost of local storage and system RAM is shrinking, because the cost of suppoting these things will bulk up the requirements of thin-client computing platforms tremendously.

At some point, there's going to be a realization that there are flaws in the web services model of computing where behaviors must cross the web service interface; the contract embedded in XML will need to extend to data as expressions of process intepretable in a common cross-platform engine, a la the UCSD p-code initiative of the 1980s, or more recently, the myth of cross-platform Java, which while stated as "Write once, run everywhere" is far closer to "Write once and debug everywhere".

>You mentioned that SQL Server and Office will be re-written eventually as .Net languages - I doubt it. It'll be too slow and too big that way. SQL Server especially will have Microsoft always trying to do write as efficient as possible and C++ will likely continue to be the main platform for building shrink wrap software, especially system software and servers.
>

I don't see either as native language or development platforms; certainly, both have an internal script language, usable to either modify internal behavior through the creation of internally-interpreted functions, but there's no capability other than as a server and consumer of other's servces really present in either; they are ideal interface exposure objects, but lack the ability to host the myriad decision processes outside of their rather limited world-view.