partitioning a conversion is difficult. So many factors depend on how well
the VFP application was written.
If your application was written to have a COM interface, you are off to a
good start. Otherwise, I would suggest that the first thing you do is
partition your application, entirely in VFP.
In other words, if your app isn't already based on front-end components that
call business components, where the business components are declared as
OLEPUBLIC, do it now. Write test cases against the COM interface to make
sure that you can fulfill 100% of the application functionality using the
COM interface. It honestly doesn't matter WHERE you draw that line through
your application, since all this code will end up in the dust bin...
however, the line must be drawn completely through the application. no
exceptions.
This is deliverable 1: a completely partitioned and automatically testable
COM interface structure that allows 100% of the functionality to be called
from a different front end than the one provided in VFP.
Then, deliverable 2, some months later, would be a completely new front end,
written in VB.NET or C#. It would call a set of objects that simply use COM
Interop to call into your VFP business objects. Those automatic test cases
will come in handy, because along the way, you will have had to make some
changes to the COM interface to make it easier for C# to call it (or to
support new business needs, as the application continues to develop new
features).
Now, you can offer two complete interfaces. The timeframe of developing
deliverable 2 should have MINIMAL front-end development on the VFP front
end. This is because you will have two branches in your source tree: one
for the VFP front end and the other for the .NET front end. You don't want
to make too many changes in both places.
After deliverable 2 is shipped and you have completed user acceptance
testing (e.g. your code base is fairly stable... exactly when this happens
depends on the SDLC and support procedures that your company uses), you can
embark on a vertical slicing of the application.
The front end work was a horizontal slice, across all functions. The next
step is to take natural groupings or clusters of functionality and replace
them in a vertical fashion: one feature group at a time. It isn't clear
what your app does, so I will refer to a retail system. You could pull off
the inventory counting and management components, and rewrite them, leaving
POS completely intact. Ship. Deliver. Stabilize.
Then pick off another vertical slice. All along the way, you may have to
add further COM interfaces where you cut apart older VFP components. Put in
automated tests as much as you can. Note: when you replace a VFP component
that has a set of test cases written against it, don't delete the test
cases. Make sure that the test cases can call your new component in exactly
the same way as they could call the COM components (minus the details of
Interop itself). I would even go so far as to create a COM wrapper for the
new .NET stuff so that your .NET interface uses COM to call the new .NET
components underneath. That way, you don't have to change the U/I code
right away. You can migrate that interface at your own pace.
After a while, this goes faster, because doing a single vertical slice will
require that you create some infrastructure code, code that you will add to
and refactor as you go. By the time you get to the last slice, you have
such a good data access layer, and you are so familiar with it, that it
should be a snap to kill off the last component.
As for which slice to pick first: pick a small but distinct one. (like the
data admin interface or something). Much of the expense of this layer will
be spent creating methods and techniques that you will re-use. During this
step, don't pick the hardest possible thing. You already have hard stuff on
your plate.
Then, after the first slice is stable, and you have your .NET GUI calling
both COM and .NET components, the second slice should be harder... much
harder. Something big and ripe and nasty. Something that needs the
rewriting. After you finish that one, your team will have all the practice
they need to pick off additional slices and push them out at a rapid pace.
Do this agile. Your requirements are fairly well understood (its your app,
after all). Depending on the size of the app, you may be able to knock the
whole conversion off in a remarkably short period of time (I'm talking
months, not years, assuming you use something like Scrum or XP).
Good Luck,
--- Nick Malik
fmr. Director of Development
Applications Architect
"Chris Brown" <cb******@store-trak.com> wrote in message
news:lWaOc.5352$NV3.3563@trndny01...
Hello,
I work for a company that sells a product with a VFP frontend/MSSQL
backend, and we have become aware for many reasons the we need to switch over to
.net. The problem is that our application is huge, and a flatout
conversion would take several years, during which time our core product would change.
It appears our best approach would is a gradual conversion from VFP to
..net.
Has anyone faced and solved this challenge before? Any ideas on what
would be more practical - to call VFP from .net or vice-versa? Any recommended
reading would also be greatly appreciated.
- Chris
