Discussion:
Migration Foxpro 2.5 to .NET
(too old to reply)
Rick Bean
2004-06-28 22:25:09 UTC
Permalink
Al,
There is no simple answer - yes, no, maybe. What kind of app is it? How big is it? (Forms, programs, reports, etc.) How much Data? How many users? Are they all connected locally, or WAN or over the internet? How time critical is access to the data? Is everything built in to the application, or do you use any third-party tools, like query/report writers? Do you have in-house expertise on VFP or .NET?

Rick
Does it add value making a migration from Fox 2.5 to VFoxPro in time and tecnology and integrating with .NET thru COM? or going direct into .NET?
John Spiegel
2004-06-29 14:07:00 UTC
Permalink
Hey Al,

What are you doing at this point with .NET? Do you have existing code that
needs to be integrated or is this a direction you're looking into? Is there
a shift in the way the functions currently provided by Fox 2.5 apps are to
be used? It's like Rick said, there are too many variables at the moment to
say one or the other, neither, both.

One guideline is based on whether the reasons that FP was the language of
choice are still effectively true today. If so, VFP is a likely choice.
For example, if this is an app for an individual office and doesn't need to
become Web-based or be spread across multiple offices, you can leverage a
lot of the code and migrate more gradually if you stick with VFP. And,
native VFP data handling is still going to be faster in a lot of situations
than pulling from a database through ADO.NET.

Also, take a look at the thread started by Chip Orange on the third, "vb or
vfp: advice needed".

HTH,

John
Does it add value making a migration from Fox 2.5 to VFoxPro in time and
tecnology and integrating with .NET thru COM? or going direct into .NET?
Lee Mitchell
2004-06-30 20:06:08 UTC
Permalink
Hi Al:

I have never done a conversion from FoxPro 2.x to .Net, so I cannot give
you any idea on the amount of time or effort involved. You might want to
expand the audience of this question by posting it to one of the forums
hosted on www.universalthread.com. They have a dedicated VFP section, but
you can cross post it in the .Net area as well. You must be a member to
post, but membership is free.

You can simply move the code from FoxPro 2.x into VFP. Normally, you don't
have to rewrite the code and only minor changes are necessary. Here are
two resources on converting FoxPro 2.x code in to VFP:

Chuck Urwiler's FoxPro Advisor article at:
<http://foxproadvisor.com/doc/05239>

Also, this is a link to an older white paper on converting from FoxPro 2.x
to VFP 5.0. While the information is a little old, much of it is still
applicable to later versions:

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarfoxgen/
html/msdn_movfox.asp

However, if you decide to move to VFP, you are probably better off
rewriting the code from scratch in VFP to take full advantage of VFP's OOP
functionality. Rewritten code will probably be less expensive to
maintain in the long run that converted FoxPro 2.x running in VFP.

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 Public Beta Now Available!! --*
Download the VFP9 beta here: http://msdn.microsoft.com/vfoxpro/

*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003
I have a good staff with .NET knowledge. But my concern is the convertion
time because I only >have one staff with good FoxPro 2.5b knowledge but
with zero .NET knowledge. My decision >point here is get out of Foxpro due
to regulation observations in the application. One of my other >concerns id
the time and adds value to move it to VFP or to full .NET. I haven't found
good >information and experience on convertion from Foxpro 2.5b to .NET.
To give some information >of the application, it's 100% Foxpro, lot's of
forms and menus with several rutines on VFP for >performance. No external
interaction, only some files extraction for other external applications.
Buy it's a big application developed since 1992. But it's time to change
with end users needs. I >see the application moving to a spread across
multiple users due to the users needs. It could be >web based or a desktops
applications but this is something that I have to decide.
Al
Hey Al,
What are you doing at this point with .NET? Do you have existing code that
needs to be integrated or is this a direction you're looking into? Is there
a shift in the way the functions currently provided by Fox 2.5 apps are to
be used? It's like Rick said, there are too many variables at the moment to
say one or the other, neither, both.
One guideline is based on whether the reasons that FP was the language of
choice are still effectively true today. If so, VFP is a likely choice.
For example, if this is an app for an individual office and doesn't need to
become Web-based or be spread across multiple offices, you can leverage a
lot of the code and migrate more gradually if you stick with VFP. And,
native VFP data handling is still going to be faster in a lot of situations
than pulling from a database through ADO.NET.
Also, take a look at the thread started by Chip Orange on the third, "vb or
vfp: advice needed".
HTH,
John
Does it add value making a migration from Fox 2.5 to VFoxPro in time and
tecnology and integrating with .NET thru COM? or going direct into .NET?
Loading...