Yeah, you need the .NET 2 framework for this sort of thing. However, it is becoming increasingly prevalent on the Windows OS and eventually a vast majority of the PC users out there using Windows will have it installed on their machines, either because it came bundled with the OS or because it was already installed to run some other .NET 2 application. If the customer doesn't have it, then they can download and install it from MS... saves us from having to include it in our install sets or in our online downloads.

The thing that excites me about being able to create ActiveX controls in .NET for use in Visual FoxPro is that we can really bring in a lot of eye-candy and new features to Visual FoxPro. It's not supported by MS (they removed the supported ability to do this in Beta 1 I think), but it is still really impressive (at least to me). There are some real possibilities here for taking what .NET does best and hosting it in a VFP application. Eye-popping interfaces with eye-popping data speed and eye-popping reports. It's a match made in heaven if you ask me, and one of the really useful things that .NET has to offer to Visual FoxPro developers. This isn't jump ship... this is steal ship (or at least those cool gold-plated paddles).

Once I have a good generic C# framework for exposing these controls (events and properties) in Visual FoxPro that also allows dynamic creation of contained controls (toolstrip buttons for instance) and databinding, I'll be able to knock these out at a rate of about 1 an hour. I've already got some of these things figured out and I haven't had much time to devote to it since I posted that blog entry. In any event, a big beautiful suite of controls that plays nice nice with Visual FoxPro might be worth downloading and installing the .NET framework.

It did strike me as odd that Microsoft would remove support for one of the things that could really sell .NET to those who aren't using it. I guess they just didn't want to deal with the inherent support issues.

>That was pretty!
>
>Are you saying to include the xNET component in a VFP app, the VFP app would need to include the 23MB NET framework?
>
>One would think our vendor (to whom we have given so much) would make sure our VFP OCX libraries are current.
>
>Maybe MS ought to get a first round draft pick from MIT so they can figure out how to trundle those controls with VFP.