Visual FoxPro to .NET migration / .NET software development

Visual FoxPro was one of the best development framework in the world for a long time. Many projects was fulfilled very perfectly and continue to work fine with providing solutions for tasks of any complexity. But world is changing. Microsoft stopped development of Visal FoxPro in 2007 and stops supporting of Visual FoxPro in 2015. Companies - owners of projects created on FoxPro have to make steps with orientation in future. Time enforces us to use new technologies.

Probably some companies wish to save most things they had in VFP project when move solution to new platform.

We can provide such wishes and convert to .NET platform a set of things. We can provide first step of migration VFP project to .NET with using pre-converters which allow to:

• Move structure of classes (tree) to c#;
• Move controls placing, form and container layouts to WPF;
• Move all commented FoxPro code into appropriate methods;
• Move view structuries as classes or entities;
• Pre-convert report forms into Telerik report forms.

As result you receive a buildable .NET-project and you are ready to rewrite code and to make project components alive step-by-step.

There is no one universal way and one pre-converter to pre-convert any project. There is a lot of styles of programming in VFP and we make individual solution for each project. But this solution is based on set of common technologies we use.

Pre-conversion of structure of classes.

Class-tree is the same as visual-tree in Visual FoxPro. But they are different in c# and WPF. Class-tree is a property of c#-language, but visual-tree (placing controls inside containers) is a property of WPF or Silverlight technology. So a task to move class-visual-tree from VFP to .NET is not ordinary. But we can solve it. We use XAML format only for controls which defined directly in forms. Controls defined as members of containers we declare and initialize in c# code of appropriate classes.

Pre-converter scans class-tree first and creates the same class-tree in c# project. Then it scans properties of each class and each member of class and adds member-declaration to appropriate class in c#. Then pre-converter analyzes members-controls and adds each control to children-collection of UIElements of parent container and does it in constructor of current class. Also it adds commented VFP definitions of properties near their c#-definitions.

Each control inserted into appropriate container directly in current class receives the name which equal to full path of object in visual-tree where dots are replaced with '_'. For example:

public class Class1 : Grid

{

public Grid Container1 = new Grid();

public Grid Container1_Container2 = new Grid();

public TextBox Container1_Container2_Text1 = new TextBox();

public Class1()

{

Children.Add(Container1);

Container1.Children.Add(Container1_Container2);

Container1_Container2.Children.Add(Container1_Container2_Text1);

So, Container1_Container2_Text1 is a member of Class1 class, but has Container1_Container2 object as parent and included into Container1_Container2.Children collection.

All methods of VFP-Text1 control became methods of Class1 and receive names of control + '_' + mertod like VS.NET does when generates event handlers. And you can't refer with this-keyword (or simply to members) to Text1 from such methods but you have to write control name Container1_Container2_Text1. implicitly. Actually we loose event-handler-assigning, and you will restore they step-by-step with parameters, types and code of methods.

Pre-converter repeats a structure of directories of VFP project in .NET solution and adds one native directory.

Name spaces structure pre-converter generates similar to VFP-project directories structure.

For each VCX-file pre-converter generates cs file.

For each PRG-file it generates cs-file. All class-definitions of PRG-file became class-definitions in cs-file. All procedures and functions of PRG-file which aren't methods of classes became methods of new static-class with name of PRG-file.

For each SCX-file pre-converter creates three files:

• FormName.xaml - XAML code of partial form class;
• FormName.xaml.cs - c# code of partial form class;
• FormName_VM.cs - "View model" code as analog of DataEnvironment of form.

For example:

PAYBYDATE.xaml lines

PAYBYDATE.xaml.cs lines

PAYBYDATE_VM.cs file in case when IdeaBlade Entity Framework using

We convert VFP controls into WPF with using of mapping:

And pre-converter copies properties of controls as:

All other properties pre-converter moves as commented code into cs-file and places close to control definition.

Because of XAML allows to place controls only inside containers in visual-tree (not as members inside classes like VFP dynamically), we use XAML format only for controls which defined directly in forms and placed into containers which defined in XAML. Controls defined as members of other classes we declare and initialize in c# code of appropriate classes. But in cases when controls placed inside Pages of PageFrame or children classes - we also define such controls inside pages in XAML code.

We use class-browser in VFP to view code of parent class. But we can't load and edit parent classes while children classes still loaded into editors. More. VFP doesn't provide a convenient way to navigate to definitions of objects, variables, classes .. like VS.NET provides.

If you plan to move code step-by-step and rewrite it immediately then you will spend a lot of time to find needed code in VFP project.

Our pre-converters copy VFP code into appropriate method of appropriate C# class and does it for all methods of pre-converted classes and forms and for all property-definitions.

For example:

And now you can make alive your code step-by-step without scanning of VFP-project. And you know how powerfull definition-navigation VS.NET provides. Just right-click any class or object in code and select "Go to definition" to open declaration.

Pre-converter creates *_VM.cs file for each form. It scans DataEnvironment of form and finds cursor-objects. For each cursor object pre-converter finds appropriate view in DBC. And next steps depends on data-access-model you select for your .NET project. It can be:

• WCF-level access with using of operation-contracts and data-contracts;
• Microsoft entity network;
• IdeaBlade entity network

In second and first cases we create data-entity model before pre-conversion. Pre-converter finds entity-type with name equal to cursor. If appropriate entity type is declared then pre-converter doesn't define additional types. But if there is no appropriate entity-type then pre-converter will create type with structure of view and places declaration into DBC.cs file. For example:

In first case (when WCF-level access selected) these definitions will have [DataContract] directive, and you can copy such declaration into your WCF-Service.

After class for next cursor is defined or found in entity-types, then pre-converter adds cursor declaration into *_VM.cs file of form as OvservableCollection. For example:

Many years we write solutions as in VFP as in c# and .NET platform.

Our VFP-solutions are capable of solve all our tasks good. But a time of VFP is over. If you need to extend your projects functionality then you have to rewrite whole project to new platform first, and then you can extend it.

c#+.NET and VFP very differ. Actually ADO.NET must replace all dataaccess technology of VFP. But ADO.NET allows inmemory data operations only. So, if you need operate with a large data on client-side of desktop application then you must use SQL Server Express in additional to ADO.NET.

Absolutely new technique of working with data ADO.NET Entity FrameWork offers. This is absolutely new way in compare to FoxPro.

As programming language c# very differ to FoxPro too. So. If you haven't got c#+.NET programmers then your FoxPro-programmers must to learn a lot of absolutely new and hard things, and they need a time to do it. And they need more time to do it perfectly and to increase solution perfomance, abilities, effectivity and to extend it. We can do it faster, and your programmers can study new technologies with our solutions we recreate to you.

First we have to study how your VFP application works to begin solution migration from VFP to .NET. Then we offer few variants of rewriting application in .NET without any pre-conversion. We also offer variants to improve and extend new solution and other steps to make it more effective.

.NET platform allows a set of new powerful technologies. Especially to work with distributed and remote data.

How many time is needed to migrate from VFP to .NET depends on strategy which we select. Each project require individual analize.

Two ways to migrate project to new platform are most common:

a) Old project still work. We take separate components of solution consistently and rewrite their functionality in new platform. Old components, which we didn't rewrite yet, still work in FoxPro, but new components we start in .NET step-by-step. You can see how we work and can suspend this process. But remember - first components need base rewriting and require many more time when other components. We don't use pre-conversion and don't take doubtful things into new project ;

b) We make pre-conversion of all components of project and begin rewrite components step-by-step. We don't need to open VFP code each time except tracing. But a lot of doubtful code might be transfered into new solution and we have to clean it. More. A lot of code will be rewrited in full because of technologies very differ. But we can increase a speed in many cases.

We offer second way not often because we use our methods and techniques which guaranteed to be different from what was in VFP. But if client wish to save a structure of project (class-tree, layouts, ...) and to repeat a functionality so close to old as possible - then we offer pre-conversion step.

Projects of any complexity. Single database or distributed data or data in clouds.

Interface: Winows Presentation Foundation (WPF) ; ASP.NET ; Silverlight.

Data access: ADO.NET Entity framework ; IdeaBlade Devforce; ADO.NET ; Windows Communication Foundation (WCF) level

In this book we create an example of application "My bills" in Visual FoxPro and then create the same example in Silverlight 3. We follow the best technique of OOP (object oriented programming). In all cases, when we can extract the similar for several objects behavior into parent classes, we do this. More than that! We don't use any galleries or additional frameworks from the other developers. No wizards. No galleries. No toolkits. ... Minimum XAML. No Entity data access. Only the lowest-level Silverlight 3 dissection.

Open book ...

DOES.NET technology allows you writing and executing expressions and scripts in NET languages without compilation. And you can declare and use dynamic variables (objects) right in scripts without compilation too. If you used dynamic languages before then you be glad receiving ability to use dynamic code, macro substitutions and other powers of simple interpreter in NET languages (C# & VB). DOES.NET is a minimal set of means to create any dynamic code (except type declarations).

DOES.NET is not alternative to CODEDOM technology in NET FrameWork , but in Silverlight (in browser) where CODEDUM is unaccessible DOES.NET can be very useful.

Open page ...