>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.

I'll give you that there's lots to like in the Windows application portion of .Net too, mainly because of the functionality that the CLR provides in general and makes available to any language, such as multi-threading, built in network services, ADO.Net (which by far is the most impressive technology in .Net IMHO). But the forms engine in particular is clunky and works with VB's model and shortcomings. Part of that is VStudio's implementation of hte form engine I suppose, but it's also things like the lack of a containership model, lack of easy formatting for data entry (can be done, but it requiires a fair amount of code! as do a lot of things) and at least at this time the lack of some controls that are common.

Some very visual things that demo well are really easy to do - but the stuff that we do all day long tends to require *alot* of code. Databinding, data formatting, can be a real PITA if you don't use the code generators (which generate a lot of code that you have to decipher if you end up customizing).
I'm not trying to take away some of things that are really cool, but many things are so non-obvious it takes a book for someone to explain it. In my book that's bad design <g>... As you move a language or environment forward it should get more powerful, but it should also get easier to use overall. People are going to be writing *alot* more code than they used to for many things...

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.

>VFP, like VB 6, will be used for quite some time to come. There will however, be a segment of the VFP developer community that will want to make the transition to .Net. There was a time, not too long ago, when there was talk about how cool it would be if the best of VB and the best of VFP could be combined in some way. I see VS .Net as filling that need. For that reason, I see an opportunity to make contributions that will aid in the transition...

I'm with you on that one. But I'm just bummed that Microsoft really never solicited input on the Windows portion of the .Net framework, which is a huge loss to everybody, because here was an opportunity to build something great that is on par with some of the other technical achievements that .Net is bringing (Web Forms, Web Services (Ok, maybe not that one), ADO.Net)... Instead what happened there's a slightly improved VB like forms engine that inherited many of the faults of that environment...

+++ Rick ---