Jess,

>To my best knowledge, you can not build .NET enabled app in a full fashion without a tool that compiles CLR. Yes, we can call VFP COM inside the .NET, and at the same time, execute .NET COM done in C# or VB in VFP app (courtesy of some folks here), but it stops there. Without a tool that compiles CLR, you can no longer participate fully in .NET technology. MS keeps on introducing new technology, I just want to be forward looking, not just today's technology (DNA, n-Tier, COM, etc.)

According to the info, i've got (from various sources) You'll be able to do about everything in VFP that can be accomplished with .NET. You can use automation to use .NET functionality. However performance hits are unknown.

I just want to see the benefits of CLR and what it means to VFP. Until this is not clear, the question for compiling to the CLR is way too early. We can't give the VFP team such assignment while we do not know what we will gain...

>IMO, no VFP feature will gone if support for CLR runtime is just an option. VFP language should be kept intact with the ability to compile CLR for us to participate fully in .NET tech.

At least we agree that compile options are needed *if* we want to support CLR.

>>To me it is a fact, that many IT folks are driven by hypes, and do not look at the facts and weigh them accurately. Let's first look at what compiling to the CLR has to offer, and then choose if we find it worth the cost or not. We can't afford to jump into the water because everyone else does....

>It's a technology issue, not hypes IMHO. I think MS won't invest billions of $ in C# and re-architecting VB without first calculating the ROI.

We both don't have any insights into MS labs, Maybe they also develop another VF7 (without CLR) if VB7 is going to flop.

>MS will not let VBers gone with the wind because of .NET. One folks in DevX says "The thing is I am making money because of VB. It might not be the best tool but bottomline is, I am making money..."

Very true,

Walter,