No move from VB to C#. This was done in C#. And the framework is the same for both C# and VB or any .NET language. Basically all of these .NET languages (even ones not from Microsoft) have the ability to produce the same Common Intermediate Language (CIL - or just IL for short - or MSIL to give MS a plug) which is then compiled into a specially extended PE format (PE format is the format used for the Exes, DLLs, and OCXs we have used for ages). Then this extended PE formatted file, known as an assembly, (.NET Exes and Dlls) utilize the Common Language Runtime (CLR) which serves basically the same function as the Java Virtual Machine does for Java (to be fair, there are a few differences between the JVM and the CLR, such as Java's bytecode is interpreted, whereas the CIL is compiled on the fly into machine code - this is known as just-in-time compilation). Anyways, throw in a few more fancy words and phrases, like manifest (just a glorified type library) or Framework Class Library and you have most of the parts that people refer to as .NET.
I've simplified some of this, but that's basically the way the thing breaks down... whether I am working in C#, VB, managed C++, Delphi.NET, or whatever, my code is going to be compiled into .NET assemblies which all have CLI in them that all tells the CLR what we want to do, so it can create machine code just-in-time to produce some mighty fancy toolbars and menus. Pretty cool stuff that can be leveraged to enhance the Visual FoxPro applications we make for our customers.
.NET is not up to snuff in a lot of areas when compared to VFP (especially data), but it beats Visual FoxPro hands-down when it comes to user interfaces, advanced OOP constructs, and web development. Rick Strahl has already stolen some of the ASP.NET paddles to create the newest West Wind Web, so I thought I would just grab us a few paddles from the other side of the .NET boat. Sedna should bring us even more paddles. Add that to all the paddles we already have in Visual FoxPro and I'm thinking we're bound to attract a few more developers grabbing paddles as opposed to lifevests that are half filled with cement. There's no reason why Visual FoxPro and Visual FoxPro developers can't utilize the .NET Framework. A little bulky? Sure. But the additional features that can be added to Visual FoxPro are well worth the stretch. I create FLLs in C++ for use in Visual FoxPro programs for the same reason... it is worth the stretch and allows me to extend Visual FoxPro... my favorite language on the whole earth... the best development product that Microsoft has... the only language I code in when I sleep... Visual FoxPro Rocks! Has always Rocked! Will continue to Rock! Where are the fireworks and the parade for this one of a kind language that does so much for me and my customers?
>>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.
>
>First - thanks for taking the time to do it. It's pretty!
>
>When you move from VB to C# - will it still require the VB.NET FW overhead?
