>You know, I'm starting to wonder if maybe this isn't a done deal! Look at the people on the wiki that are pushing this notion of removing VFP. They're all the top developers for VFP. Do you think Mike and company have already been told it's coming out and they are trying to soften the blow? I'm betting since these guys are tauting it, it's already a done deal! That's the only thing that makes sense. Why else would you remove a product from a suite that will have much more marketing exposure? It's all about marketing anyway - isn't it!

I don't think so. There are a few important names in the "drop it" band, but I think the debate is just starting.

I'm increasingly convinced that dropping it from VS would be to cut some possible prospects of better integration with the .Net framework. I understand that VFP is not absolutely related to the whole .Net strategy right now, but if things go slightly as MS plan, in just a few years every development tool would fall there anyway.

Trying to imagine alternatives to the problem of porting VFP to the CLR and .Net classes, I thought that it may be a viable way to adapt VFP own C++ source code to .Net, maybe mapping many VFP things to .Net equivalents, and keeping the local data engine and other particular features.

That way, we would not be able to run on the CLR, but OVER the CLR. Maybe the execution would be not the same as other languages, but we already have an interpreter! And besides speed issues, we could gain many of the stability and security issues, and -who knows- perhaps a thighter integration with the rest of the languages, even as we keep a different IDE.

Have anyone else analyzed that possible path?