>>I doubt that its true & I suspect the speaker doesn't know either.
>>
>
>I've stayed out of the VFP7/.Net threads so far, but I'd say that VFP7 is particularly attractive as a hedge against .Net -not- being thoroughly accepted by the developer community. We're retaining the now well-established and, while complex, fairly stable COM interface for our components; we can still play in the managed code arena with the Interop layer, but even more importantly, can play in existing COM-compliant envinronments if it turns out that the CLR/managed code arena is 'a bridge too far' and reliance on the .Net paradigm is not broadly accepted. VFP7 can play in the current n-tier, COM- and DCOM- deployed environment used today. If .NET is not broadly accepted, the effort in learning VFP7 enhances our ability to work with the environment in use now, we get better hooks to COM in any case, the addition of implementation inheritance and the ability to retrieve a COM interface from the API in VFP7 improves how we can interact in the current COM environment significantly.
>The single biggest issue, the ability to fit into other threading models that are exposed as .NET resources appear to be the biggest threat to the viability of VFP-developed business objects; lack of access to some thread issues make it difficult to scale VFP objects compared to things running in the CLR with the thread resources. We have extra layers involved in subclassing our objects in .NET, but that's only an issue if .NET becomes the dominant mode of deployment, not presently a clear issue.
>
>Investing time in VFP7 seems to be a good hedge against .NET not being accepted immediately; it enahnces what we can do now, and while not a direct CLR player, it benefits by remaining deployable without the .NET CLR environment.
>

Interesting reply!
We are NOT going with the .NET at our offices.
Apparently we won't be going W2K either...