My answers to the questions:

>>"So, if we need to do web apps, we will have to learn VB.NET and ASP+ for the user interface?"

Not necessary so. You can build web apps today. What VS.NET will bring you is a level of abstraction on top of all the standards: SOAP, HTTP, etc. This will make it easier to build distributed web apps and take advantage of web services. Today you use VBScript and ASP calling VFP components. Tomorrow in VS.NET you will use VB/C# and ASP+ and call VFP components and/or web services.

>>"Can a CLR app (i.e. VB7) be a simple Windows desktop app?"

Yes. I showed at the DevCon keynote a Windows form that was consuming a VB7 class and a VFP component. One of the options in the .NET framework is Windows forms. They take total advantage of the Windows interface and don't use the browser to be rendered. It can be created simply by dragging and dropping components in the Windows form designer in VS.NET.

>>"For someone who is starting a web based app, which should be the best way to follow? Wait for .NET? ASP with VFP COM server? Anything else?"

That is an interesting question. My recommendation today is to look at the options available today and evaluate: ASP with VFP COM, Web Connection, etc. I I think that the most important thing to do regardless is to make sure and componetize whatever new app that is being written today to make sure that the tiers separate (presentation, business logic, data, etc). This will make the app easy to move around in the future.

>>"Does COM+ mean that I have to have an NT Server (are COM+ services available on Win98?)."

COM+ (Transaction Services, MSMQ, etc) are not available in Win98. You need to have NT4 with the option pack or Win2000.

>>"How do I make my VFP COM components .NET compatible?"

To build them, nothing really. You either need to expose them as components or as web services today with the SOAP toolkit or later with VS.NET or VFP.
The interesting part of well architected .NET-compatible components though is that they need to be written as stateless. There are many documents about writing good distributed, scalable apps and they all talk about not keeping state. I'm sure that Rick Strahl can give a whole presentation about this <g>. An example: a method that opens a table, searches and returns a value. If you keep the table open and the record locked then you're keeping state. You need to make sure that all links to the data are closed when the method is done executing. Again, there are plenty of examples and publications on how to create stateless components. Actually, the ADO+ dataset is a good example of a disconnected, stateless component.

>>"Will VFP7 be called VFP.NET?"

We haven't made that decision yet.

>>"SOAP is now available from MS site. Are there other development tools that will be valuable and that are going to be a part of VS.NET?"

SOAP is not really "available". SOAP is an XML protocol like HTTP POST that has been standarized by the WWWC (World Wide Web Consortium). What is available from the MS site is the SOAP Toolkit. The Toolkit has the capacity to create web services from COM components and consume them too from VFP6/VB6 and later from VS.NET. I think that the most valuable "tool" available today that is part of .NET is the .NET framework that you can download from the Microsoft/net site. I know that people like Rick/Markus/other gurus are on top of .NET and am sure that they're thinking about providing tools and help for VFP developers in this area.