HomeBlogLearnProductsEventsServicesAbout UsFAQ
Mike Yeager's Blog

Friday, September 07, 2007
VFP Conversion Tools and running into old friends on "the internets"

A co-worker ran across some questions about VFP to .Net conversion tools on the Universal Thread. I checked it out and ran into a few old friends as well. I swapped a couple of emails and got caught up, then posted some information about our products for the curious that I'd like to re-post here...

My name is Mike Yeager and I'm the lead developer on the conversion tools from VFPConversion (part of EPS Software).

We'll be updating our web site as soon as we can get to it, but here is some info on the most asked about tools. The cost for the conversion tools is from $1-3K each, depending on the type of license / user.

The Project Analyzer is a FREE tool written in VFP that compiles metrics about your VFP projects. This information is very helpful when trying to determine the scope of a conversion project or even just documenting your investment in VFP. There is also a premium version which costs $129 that gives you much more detailed information by drilling deeper into the source code. It includes information such as the average # of commands per method for a VCX, the number of sub-classing levels for forms, controls and classes, etc. This helps us determine the quality of the code and how well the architecture might convert to .Net.

The Report Converter which converts from FRXs to SSRS has been released for quite some time now and is getting really good feedback. If you're interested, contact us and we'll convert one for you for free. From FRXs to Crystal Reports is not yet ready for prime time.

The Forms Converter has recently been released! It converts all visual classes in both SCXs and VCXs. We don't generally do free samples on this one because most people's forms rely on many, many VCXs and those all have to be converted as well. With this tool, you can configure your target to be plain vanilla .Net controls, Milos Solution Platform controls (EPS's own .Net Framework), Developer Express, Mere Mortals, etc... We have not tested all target frameworks thoroughly, but so far feedback is very good.

We've used both of these tools in projects we've worked on in-house. They're both very fast (measured in forms and reports converted per second!) and they save a LOT of time, especially on large projects with hundreds or thousands of forms and reports.

It's true that we only address the most time-intensive conversion tasks. After having done many conversions and we are constantly looking at all of the conversion techniques out there (including VFP compilers for .Net, calling .Net forms from VFP, calling VFP forms from .Net and many others). We've concluded that a comprehensive automated VFP to .Net conversion just isn't plausible. To be sure Conversion projects, if they are of any size at all, will not be cheap in terms of time or money (if you pay someone else to have it done), however they are much less expensive than a ground-up re-write.

We'd love to talk to you about it if you're facing a conversion project. They're not easy and they're not fun, but they are possible and there are many success stories out there. There are lots of free resources on the VFPConversion web site including a conversion roadmap, white-papers, technical articles about specific tasks, etc.


Some automation is almost always possible. We've even taken forms defined in .PRG files, saved them as classes in a .VCX and then converted them to .Net forms!

In all likelihood, you probably want a new architecture for your .Net app anyway, even though you may keep significant pieces of your existing app. Here are some of the big differences you'll find in doing a conversion:

1) Most .Net apps are architected differently than VFP with well-defined tiers. It's much easier to do when you can create and use .dlls (not the COM+ kind) in your development environment.
2) .Net apps have no concept of dataenvironments that span classes or tiers.
3) .Net highly discourages visual inheritance - subclassing visual controls, containers and forms the way it is so commonly done in FoxPro.
4) .Net uses client-server data access technology - you almost NEVER have full access to an entire table at once on the client side.
5) Until LINQ is released with VS2008, you can't query data in memory - all queries have to be run on the DB server. Even when LINQ IS released, it takes a lot more work in VS than it did in VFP.
6) VS has strongly typed languages - variable and parameter data types were never defined in most VFP apps and it's quite common to use multiple types of data in a single variable or parameter in VFP - IIF(condition, 1, 'ERROR') doesn't work well in .Net!
7) VS has only limited ability to run code on the fly (macro substitution, executing uncompiled source code, etc).

In practice we find that most the code itself is cast aside used only for reference when writing the new app in C# or VB. Entire sections of code devoted to things that were complex in fox are rewritten in a few lines in .Net and vice versa. The things that carry over best are SQL statements.

Even if the project architecture doesn't lend itself well to conversion, a tool like the report converter is often used. If you have 150 reports in your project and the converter saves you just 1 hour per report (in our experience it's a lot more than that) then it's more than paid for itself - plus your conversion project is now ahead of schedule by all of those hours. If you hae 2,000 reports - as some large projects do...


Posted @ 4:31 PM by Yeager, Mike E. (myeager@eps-software.com) - Comments (114)

Friday, September 07, 2007
VFP Conversion Tools and running into old friends on "the internets"

New message

Posted @ 4:27 PM by Yeager, Mike E. (myeager@eps-software.com) - Comments

Blog List
VFPConversion Blog
Markus Egger's Blog
Ken Levy's Blog
Claudio Lassala's Blog
Blog Archive
March, 2008 (1)
February, 2008 (1)
October, 2007 (1)
September, 2007 (2)
July, 2007 (1)
May, 2007 (3)
March, 2007 (3)
January, 2007 (2)
December, 2006 (1)
October, 2006 (2)
September, 2006 (2)
August, 2006 (6)
July, 2006 (3)
June, 2006 (2)
May, 2006 (4)