>>I agree that it would be very difficult to provide this level of support for the CLR. Would it be any more difficult than writing an X86 compiler? Perhaps that's an unfair question since VFP relies on a runtime.
>
>Oh, am I going to regret this.
>
>The question shouldn't be how difficult is it to make VFP work with the CLR. The question should be what are the reasons for making VFP work with the CLR? Continuing the existence of VFP is not really a valid response to this question. Are there others? I'm not saying there are none I just haven't seen any stated thus far.

At this point, I don't think there are any good reasons for working with the CLR, so I won't start another thread. In the future, the market may demand it. At that time, it may make sense to keep the investment in existing code by making it run on the CLR. Then again, it may not.

>If there are no reasons then the removal from VS becomes more logical. My name is on that wiki as being against removal because I think it will be the death nell of VFP but I've always accepted that the day would come when Fox would no longer be viable.

Actually, VFP is much stronger and has held on much longer than I would have expected. As a former OS/2 user, I know how it feels to be completely ignored by a company. It least we're not that bad off.

>If you have a reason for making VFP work with the CLR how about starting a separate thread so the discussion can focus on that issue.

To tie this back in with the main thread, future CLR support could be hampered by removing VFP from the box right now. Mike Feltman said he thinks we could get back into the box later if it makes sense. I tend to think that if we get out, we'll have a hard time getting back in.