>1) After reading Rick Strahl's last couple of FP Advisor articles on integrating .Net with VfP, I've developed a perception that distributing desktop applications is troublesome if users have an OS older than Win2000. Is this an accurate perception? How easy is it to distribute desktop applications? In VFP, it's a snap with Installshield.

Yeah, I'd say it's an accurate perception. VS.NET desktop apps. are definitely going through some growing pains. I'm sure MS is working hard on fixing them, but right now it's not as easy as it should be. Read Rick's other article about .NET here: http://www.west-wind.com/presentations/Editorials/TwoFacesOfDotNet.asp

I think in most respects, his article is dead-on.

>
>2) I see significant advantages to continuing to use VFP as the backend. It's fast, it's freely distributable with a licensed copy, and maintenance is much easier and straightforwsard than server based backends (at least that is my perception). What kind of performance hits would I take using VFP as a backend to .Net, versus VFP as a backend to VFP? Also, one great thing about MM for VFP is the ability to swap in backends to the same app. How well does MM .Net handle this?

You can easily swap between the OleDb and the SQL provider in MM.NET. That means you can switch between any kind of backend that has an OLE-DB provider. I haven't done any performance testing with the overhead of the OLE-DB provider, so I can't tell you how much of a hit you'll take. It won't be as fast as a native VFP app, though.

>
>3) I consider myself an advanced VFP user, an advanced MM user, and I have a strong grasp of OOP, UML, ORM and ER. I use them on a daily basis. Any thoughts as to the learning curve going into .Net? Is using the MM framework going to speed up the learning curve or slow it down?
>

I found C# pretty easy to pick up. One thing that helped me was to take an existing class I had written in VFP and try porting it to C# / .NET (VB.NET or any of the .NET languages would work just as well). That way I wasn't focusing on the design part of the problem. I could focus in on the specifics of the language. I think most VFP developers will be able to handle the language differences pretty easily (with either C# or VB.NET). The harder part is figuring out all the .NET classes and where things are located. Again, it helped me to rewrite an existing class to help learn some of this.

I think the MM.NET framework will help take away some of the pain associated with .NET development (like any good framework should). Some people like learning the "hard" way to do everything before they make the leap to a framework. I've never had the luxury of having enough time to go this route. I tend to start with a framework and learn more on a "need to know" basis. I guess it depends on your style of learning.

For me, .NET isn't far enough along to consider using it as a replacement for all my VFP desktop apps. I'll let Kevin & MS continue to work on addressing the shortcomings before I'd consider a full switch (and I'm sure I'll still use VFP when/where it makes sense).

ASP.NET, however, is a MUCH better platform for web development than ASP was/is. I wouldn't hesitate to use it for web development right now.