Abstract
This whitepaper discusses strategies for managers converting Visual FoxPro (VFP) applications to .NET, and lays a foundation for producing an implementation plan.
Introduction
Much like you could translate Greek classics into modern English, you could translate VFP applications into .NET. Unfortunately, all of the same pitfalls apply. You could choose to automate the conversion with language conversion software, but your result, aside from pure comic value, would be a truly inferior, rough translation.
You should not convert a VFP application to .NET with the touch of a button. Converting an application requires planning, effort, and resources. Your staff will most likely need training not only for the conversion, but also to maintain and enhance the application in the future. The good news is this: you can take control of the process, use tools to drastically reduce the effort required, and get help in the form of training and staff augmentation. Often, you’ll end up with a better application than your original. After all, there are always those things that, looking back, we would have done differently, and a conversion can be an opportunity to tackle those things.
Overview of the Process
Translating a large application can be overwhelming. This whitepaper outlines a plan to begin your task in a logical and approachable fashion. The following illustration shows the logical sequence of steps taken during a conversion project:
Figure 1: Each step outlined in this illustration is a methodical, stand-alone task. In the following sections, we provide more details about each step.
Developer Training
Visual FoxPro developers have a unique skill-set that comes from working with a product that effectively covers all three layers of an application (front end, middle tier, back end). Many of these developers are already accomplished SQL Server developers, and most Visual FoxPro developers have successfully transitioned to VB.NET or C#. VFPConversion.com and its partners, Oak-Leaf Enterprises, Dash Point Software and West-Wind Technologies offer training, mentoring, and support for developers wishing to transition their skill-sets and domain knowledge into .NET technologies. Visual FoxPro developers gain a lot of benefit from training, not only for the conversion process itself, but also for ongoing maintenance and future growth of their converted system. As such, companies should plan training as part of their long-term investment in any application conversion project.
Set Goals
Transitioning from Visual FoxPro to .NET will require many judgment calls. The goal of one project, for example, might be to convert a VFP application to .NET exactly as it is, while another project’s goal might be to update the appearance of the application without disrupting workflow. Yet another project might warrant a complete re-write to take advantage of new workflows and incorporate a new architecture. Setting goals is the first step in an effective conversion project.
When you set goals, make sure that you involve all project stakeholders-across disciplines and parties. Different groups may define their goals very differently. While more technical stakeholders may want to keep software and technologies up to date, marketers may place more value on a professional and intuitive user interface. End users, on the other hand, may be concerned chiefly with specific features and enhancements. The people who will maintain the deployed applications may worry most about their ability to maintain the application-both in terms of the application itself, as well as the bigger picture of maintaining a system of applications.
You should not confuse goals with requirements. You might have a goal, for example, to “support Windows Vista”, “support geographically separated deployment within a single data center” or “use SQL Server or Oracle as your database.” Goals often address large pain-points of the current system, whether for sales, customers, administrators, or support staff.
When you collect your goals, it’s best to err on the side of having too many goals, at least initially, so that everyone involved develops a strong understanding of the current system’s overall concerns, as well as the philosophy of the new system.
In most scenarios, you cannot implement all goals. You may simply have too many of them, or the goals may conflict. A good way to choose your project’s goals is to list and prioritize them according to the “MuSCoW” (pronounced Moscow) principle, which prioritizes all goals into must-haves (Mu), should-haves (S), could-haves (Co), and won’t-haves (W). You can immediately dismiss won’t-haves. You will likely base whether or not to consider the could-haves on how much time and money are available, and how long the lists of should-haves and could-haves are. In most scenarios, you’ll dismiss the could-haves as well.
At the end of this process, you’ll likely end up with a relatively short list of high priority goals. Typically you’ll have 3-5 must-have and 5-10 should-have goals, though actual numbers will vary.
VFPConversion.com can advise you about the feasibility of goals, as well as advise you on current and upcoming technologies that should or should not be considered and why.
Define Metrics
In order to manage a conversion process of any size, you should establish metrics to provide measures of progress. Defined metrics add visibility and predictability to larger projects. Knowing, for instance, that your project has 34 forms with complex UIs, 164 with moderately complex UIs, and 52 with simple UIs, you can determine roughly the effort required to convert the UI portion of the forms, track your progress, and adjust your estimates as work progresses. Appendix 1 contains a sample spreadsheet listing common metrics for a Visual FoxPro project. Free tools like VFPConversion.com’s PJXAnalyzer can analyze your VFP projects and produce metrics to get you started.
After documenting raw numbers to show the size of the project, you should consider the project’s technical difficulty. For example, a project using VFP data environments with remote views to a SQL Server database in all of its forms will be easier to translate to .NET than one that opens local tables haphazardly throughout the code. Next, establish the estimated hours required for each type of task, based on technical difficulty. Multiply the raw numbers by the hours, and you’ll begin to see the bigger picture and the level of effort required. Prototyping forms, reports, or bits of logic is a great way to test your estimated level of difficulty and adjust your numbers before beginning to schedule work.
Define Schedule
As with metrics, a defined schedule helps give your project insight and clarity. Schedules will vary with project goals, constraints, and philosophies. At this point, the schedule is not a timeline with deadlines and milestones. Rather, it functions as a plan that you can communicate and monitor, providing management with status and insight into the project. It provides a roadmap of the work to be done and the order in which it will be done. Don’t forget to include a place up front to prepare for the project. Include tasks such as choosing a framework, configuring source control, training, and project management. Remember that metrics multiplied by hours is only a portion of the effort that will be required for the conversion.
The time for adding timelines and deadlines to the schedule is after you have some implementation experience. On the other hand, if you’re using a consultant familiar with VFP to .NET conversion projects, timelines and deadlines can probably be added earlier.
Plan Value-Adds
One of the best aspects of converting to .NET is the ability to leverage functions not available in Visual FoxPro. Incorporating Value-adds into your conversion process is a part of every aspect of your project. For example, if you’re translating an invoicing application that formerly went against DBFs, you may want to take advantage of the transaction support in the new data store. It may, for example, allow you to rip out many lines of code that protected your VFP application from deleting an invoice header record and orphaning the line items. You may want to use background threads to make your forms appear faster and be more user-responsive. See this whitepaper’s “Value-adds” section for a list of those you may want to include.
Convert Data Storage
If your current application stores data in a FoxPro database or free FoxPro tables, you may want to migrate your data as the first implementation step in a conversion process. If you’re already using SQL Server, Oracle, or some other back-end such as MySQL, you may be nearly (or already!) there. If you’re currently using DBFs and are using local views for data access, you’re in a good position, too; after the data is migrated, you can trade your local views for remote views with very few changes to your application.
If you’re currently using DBFs for storage, you’ll find many advantages to moving your data into SQL Server or other managed RDBMS. The benefits include nearly 100% up-time without the necessity of packing tables, and the ability to keep the database online while backing up and rebuilding indexes. In addition, SQL Server and other managed RDBMS provide some great security features. Of course, DBFs have advantages too, but they pale in comparison.
Convert User Interface
Converting UI components (such as forms, reports, and menus) can occur before, after, or concurrent with the data storage conversion. Even if you want to overhaul the application by re-writing your forms, you may still want to use a conversion tool to convert your current FoxPro forms, controls, and reports to .NET forms, controls, and reports (probably functional but not refined) to provide process placeholders. Conversion tools can make short work of the process’s visual conversion stage, giving you valid .NET forms, controls, and reports. The visual conversion of report layouts is an especially good candidate for a conversion tool. Having a quantifiable set of forms and reports can add predictability to your project and figure heavily into your estimations. Strategies for translating forms will provide more predictability. For example, you may have lookup forms with sortable grids bound to entire tables that perform incremental searches. Having a non-DFB back-end will mean that many of these forms will have filtering criteria added to them before the grid is populated, since you can’t efficiently browse all of a million-row table stored in SQL Server. After your back-end filtering criteria has defined and retrieved a data subset, the grid can still function like always.
Convert Data Access
Visual FoxPro’s tremendous flexibility made it possible for many VFP applications to access data directly.
Figure 2: Data Access inVisual FoxPro
Figure 3: Data Access in .NET
Developers often integrated business rules into all areas of their VFP applications. In .NET you’ll build a data access layer to give you independence from your data store, and business objects will give you the equivalent of a firewall between your data and your UI. A premium solution such as the Milos® Solution Platform will automate much of the data access for you, based on information in your data store, and will follow best practices to provide a more flexible system. Whether you choose a third party solution for the data access and business layers, or you intend to roll your own, you should plan on including these layers. The .NET environment is not nearly as flexible as VFP in many areas, and you’ll run into trouble later if you don’t include these layers. As you build your business objects, you can use them to bind your data to your UI and testing CRUD (create, update and delete) operations. By separating the data and the UI, you can now test the business rules and data access incorporated into your business objects independently of the UI.
Convert Application Logic
Translating your application logic from VFP to .NET generally requires the most resources. Just as you cannot automatically translate a Greek classic into modern English, you cannot automatically convert VFP code into Visual C# or Visual Basic.
Conversion tools can give you a head start by copying VFP code into a .NET counterpart as comments, so that you can count VFP programs, functions, procedures, methods, and events, allowing you to schedule and monitor an application’s conversion. Even here, however, there is a process to follow. You first want to map control structures, and then variable declarations, followed by commands. You can incorporate tools like the Milos VFP functions library to provide native, managed .NET equivalents to most VFP functions, so that, for instance, your developers don’t have to write their own .NET equivalent of VFP’s ALLTRIM() function. You can also use the Milos expression execution tool to convert or evaluate entire lines of VFP syntax to .NET. This is especially useful when converting reports, so expressions used in reports don’t require re-writing.
Some (Visual) FoxPro applications feature hand-coded application logic (often within the user interface), while others follow a more modern approach with a clear(er) separation of application tiers. Some even provide a rules engine for parts of the application logic. Applications that contain hand-coded business logic without much separation between application layers are the hardest to translate. Systems with clear separation between tiers provide a much less challenging conversion scenario. If a separate rules engine exists, you may have a dramatic conversion advantage-especially with VFPConversion.com Expression Evaluator Tools, which may be able to migrate your rules to .NET with little or no re-write.
Tools
Assessment Tool
This white paper includes a sample spreadsheet as an addendum to help you assess your conversion situation. VFPConversion.com is developing a tool named PJXAnalyzer that reads your FoxPro project files and gathers project metrics for you. PJXAnalyzer will be posted on the VFPConversion.com Web site when available.
Data Conversion
If your data is already stored in a managed RDBMS, such as SQL Server or Oracle, there may be very little for you to do. Still, this is an opportunity to improve on your design. If you’re not currently using stored procedures for all data access, consider it for your conversion process. Changing to stored procedures is much easier to do during the conversion than to retrofit afterwards. You may have some legacy structures and column types that would benefit from updating, and the period when you want to convert your data is the perfect time to make those changes.
If you’re using VFP tables to store your data, especially in older systems, you’ll likely have to make some significant changes to your database before you’ll be able to migrate to a managed RDBMS. Your new environment will benefit from having a primary key on every table. Functions such as UPPER() and DELETED() aren’t tolerated in indexes and you can take advantage of new features such as automatically populated GUID column types. You’ll also need to decide which index to choose as a clustered index, if any. Data conversions can take a few days or a few weeks for a developer or DBA familiar with both Fox and the new platform. Once a process is established, the conversion will usually be run many times and will be adjusted often as the conversion evolves.
VFP to SQL Server
The VFP Upsizing Wizard is a good starting point for projects where data is currently stored in DBFs and will be moved to SQL Server. This wizard, however, is sometimes overwhelmed if your DBF has a large number of tables. A work-around is to convert 50 tables at a time. Pay close attention to the SQL Server data types that the VFP Upsizing Wizard converted. The Upsizing Wizard converts FoxPro’s CHAR types to CHAR types in SQL Server where you should probably use VARCHAR types instead. A good rule of thumb is to use the VARCHAR type for columns over 10 characters wide that are often not filled (such as FirstName).
SQL Server indexes are quite different from VFP indexes, though their purpose is the same. Here are a few tips for converting to SQL Server indexes:
- Remove all VFP indexes and create them in SQL Server as needed.
- Change your primary and foreign key strategy for SQL Server. As a primer, read the SQL Server Books Online topics regarding clustered indexes and covered indexes.
- Remember that in SQL Server, you cannot use functions for index expressions.
In some ways, SQL Server simplifies things for you, since indexes are, by default, case-insensitive, and since there is no concept of a deleted record. This eliminates the need for the two most common functions used in VFP indexes: UPPER() and DELETED().
Advanced VFP to SQL Server
If the Upsizing Wizard doesn’t cover your needs, you’ll want to use either Data Transformation Services (DTS) in SQL 2000 or Integration Services in SQL 2005. Microsoft designed these services to perform complex ETL (extract, transform, and load) operations, and can do anything from simple data transformations to advanced transformations and data scrubbing. They can even run scripts and custom software, and provide workflow management and notification. These services will use either the VFP OLEDB driver or the VFP ODBC driver to read your Fox databases and/or free tables. There are some known issues with the VFP OLEDB driver, but work-arounds are generally available.
VFP to Another Database
If you’re not targeting SQL Server, you can use the VFP OLEDB or VFP ODBC drivers from your target database to provide access to your Fox databases and/or free tables. If your target database does not support import through OLEDB or ODBC, there are a couple options: (1) you can export your Fox data to a format readable by the target database, (2) you can use a third-party tool or service, such as Island Technology’s data transformation service, or (3) you can use SQL Server DTS or Integration Services as an conversion tool. Microsoft’s SQL tools will transform data from one source to another, and there’s no limitation requiring that either is SQL Server.
Form Conversion
Typical business applications contain many forms. The prospect of re-writing all those forms is daunting-and can consume a conversion budget very quickly. In some cases, you’ll decide to re-write the old form formats, but in most cases, you’ll rewrite only a few, either due to budget constraints or because the existing format works well for users.
Visual FoxPro forms could have been created programmatically or visually, stored in VCX files. Forms could contain either controls from the VFP base classes, or controls sub-classed from the VFP base classes and stored in VCX files. In addition, many VCX files could be involved. A form stored in a VCX file, for example, could be a sub-class of a form stored in another base class, which was itself sub-classed from a form in yet another VCX. All of the form’s controls could come from VCXs that may be based on controls in other VCXs, and so on-and they may have been added to any of the form sub-classes at any level. You’ll have to decide whether to preserve the sub-classing hierarchy in .NET.
Tools such as those available at VFPConversion.com can convert the visible aspects of forms from VFP to .NET. Different versions of the tools allow you to convert one form at a time, or groups of forms all at once. You can preserve the sub-class hierarchies by having the tool recreate individual classes and source files, or flatten the hierarchy and produce a single form that incorporates all the settings in the VFP source. VFPConversion.com also offers data environment conversion tools from to recreate the Fox form’s data environment.
Report/Label Conversion
If your application contains many reports or labels, or if it incorporates reports outside of the application, then manual conversion is not an option. Reproducing the visual layout of even a very simple report can consume hours of developer time.
VFP report conversion is one area where a high level of automation is possible. If your VFP application used local or remote views in the data environment of the report or the form used to run the report to derive the data used in the report, then much of the data acquisition work can be converted automatically as well. VFPConversion.com provides several versions of tools that can convert reports from VFP to .NET.
Data Environment / Data Session Conversion
Visual FoxPro’s flexibility in data environments and data sessions can make this one of the most difficult conversion tasks to automate. Ideally, each form and report would use a private data session containing only local or remote views. This highly-structured configuration lends itself to automated conversion and it most closely approximates the .NET environment. VFP, however, encourages a dynamic data environment. Consider that the USE command can work against a base table (DBF), a local view, or a remote view, and that tables can be introduced to the data environment as the result of a command such as a SELECT or through SQL pass-through. In addition, adding tables to or removing them from the data environment can be done in code scattered throughout the application. If your application employs consistent methods for creating data environments in code, forms, and reports, then tools can help you with most of the heavy lifting when converting your data environments.
Note: Until Microsoft releases .NET 3.0 with new LINQ functionality, .NET does not have a data manipulation engine beyond the rudimentary capabilities in ADO.NET’s DataSets and DataTables. This is very similar to working with xBase languages before the introduction of ANSI-SQL syntax.
Menu Conversion
Because most applications use few menus, there are currently no tools available for converting menus from Fox to .NET. While technically possible, the effort required to create the tools currently outweighs the benefit.
VFP Expression Executer
Libraries are available that incorporate the majority of Visual FoxPro’s native function calls into .NET. These libraries allow you, for example, to call a .NET version of VFP’s PROPER() function for which there is no equivalent in .NET. These libraries not only provides functionality that VFP developers might miss in .NET, but it also flattens the .NET learning curve, as VFP developers will find a more familiar environment.
In addition, VFPConversion.com has a VFP expression evaluator that allows you to run expressions in VFP syntax natively in .NET, entirely without the need for Visual FoxPro Runtime. For example, an expression such as “PROPER(Customers.FirstName) + ' ' + PROPER(Customers.LastName)” can be executed by the provided Eval() method, just like it can be evaluated within Visual FoxPro. Notice that the function referenced by this expression is not normally available in .NET. Instead, the VFPConversion.com Expression Evaluator tool contains all functionality needed to evaluate and execute the expression in a fashion compatible with VFP. Note, also, that the Expression Evaluator incorporates support for operators (in this case +). The entire expression is evaluated, and a properly typed value is returned to .NET. A special version of the Expression Evaluator tool converts VFP expressions to .NET expressions at conversion time instead of at run time.
Value-Adds
Visual FoxPro applications are often very sophisticated. However, using .NET (and its sub-technologies; e.g., ASP.NET, Windows Forms, and Web services), many new features and abilities become available. During conversion, it’s often possible to add some of those features to the converted application without much extra effort.
The following is a list of potential value-adds. This list represents only some examples and is not intended to be exhaustive.
- Standards Compliance and Control Face-Lift - While converting, why not make sure your UI’s follow modern standards and use the most up-to-date types of controls? Why not automatically change that textbox for date entry to a more modern calendar control?
- Resizable Forms - Various .NET UI technologies provide great ways to support professional resizable-even scalable-UIs. Some of these technologies are also available in VFP, but few old applications have been retro-fitted with those features. While you are converting your UIs, why not take advantage of these new options?
- Windows Presentation Foundation - You have an old Windows application and want to ensure it converts to something truly state-of-the-art. Why not convert directly to WPF, and have something you can use and build on for the next 15-20 years?
- HTML-Based Web Applications - The Internet is here to stay, and you shouldn’t ignore it. ASP.NET is a great Web development tool, and as you move your Windows application to .NET, there are great ways to add Web functionality. Even if you’ve used Web Connection (or other VFP Web tools) before, you’ll find a whole new world in .NET, with fascinating technologies like ASP.NET’s Atlas AJAX implementation.
- Mobile Devices - Did you know that mobile device development (PDAs, cell phones, etc.) in .NET is almost identical to WinForms development? Perhaps this is a good opportunity to add mobile device support to your application without a huge effort.
- Incorporate Data Access / Data Logic Layers - Perhaps you’ve always liked the concept of a multi-tiered application, but it was too late to retro-fit your existing VFP application. When you convert to .NET, you should abandon the monolithic behemoth and separate things a bit.
- Service-Oriented Architecture - OOP is great but an additional “orientation” has established itself in recent years: Service-Oriented Architecture (SOA). While you convert to multi-tiers, you should also make sure those tiers work well as SOA building blocks.
- Static Analysis - This great concept, provided by .NET, is basically an automated code review. It’s excellent for making sure your staff does things correctly and consistently. It’s also a great learning tool. Adding Static Analysis is simply a configuration switch. Don’t skip this great advantage!
- Unit Testing - Do you sleep badly the night before a release? Are you sure all those changes that crept in work without breaking any existing functionality? Unit testing can answer these questions quickly and painlessly. Unit testing is also available in VFP, but not nearly as easily and reliability as in .NET. You shouldn’t build a .NET project without unit testing. (Nor VFP project, for that matter, but that’s a different story altogether).
- Multithreading - Multithreading isn’t for business applications, you say? Think again! In VFP we generally dilute ourselves into this belief, while the entire industry is rapidly moving toward a massively-threaded approach. Modern applications that support distributed architecture shouldn’t ignore threading if they want a professional result. Luckily, multithreading is easy to implement in .NET.
- Security - Security isn’t a strength of most VFP applications. Modern applications, of course, must be secure! So while converting, build security into the design at the beginning to ensure your application’s competitiveness. Every line of code in your application has a certain degree of security, and, by default, it will probably fall on the low end. So make sure to use the plentiful tools and techniques available in .NET to build a secure application. Incorporating strong security usually requires the same amount of effort as ignoring it; it’s just a matter of taking the right approach.
- Strong Typing - Strong typing is one of the most powerful tools in .NET’s quality arsenal. Unfortunately, VFP developers often misunderstand or overlook it. Make strong typing a high priority on your training schedule.
- Office Development - Microsoft Office is important, and your application should probably work well with it. You should consider adding standard Office-features (such as export or synchronization) across the board while converting, resulting in serious benefits for your users.
- OS Callbacks and Windows-Message - Using .NET, developers have more sophisticated direct access to Windows and its many features previously unavailable to VFP developers. Perhaps this is a good time to remove some clunky workarounds, or to add features that integrate more directly with Windows.
- Web Services - Web services offer a whole list of advantages, starting with the ability to architect your own application in a way that supports distributed scenarios better. Now is a good time to evaluate the possibilities.
- Network Programming - .NET provides the ability to integrate more directly with low-level information, such as network availability. For instance, it’s relatively easy to figure out whether a network connection is available, and whether or not that network connection provides access to the Internet. Using network programming may help you eliminate some nasty error messages and odd workarounds.
As you’re converting your application, many of these value-adds can be implemented with a relatively small amount of effort. Some, in fact, can be incorporated in the conversion effort with no more or less effort than a conversion without the value-add.
Windows Presentation Foundation (WPF)
Windows has used the same user interface technology (GDI) since its earliest versions. Microsoft will replace GDI with a new technology, Windows Presentation Foundation (WPF), although the transition won’t happen overnight. Those in the know expect that Microsoft will base Windows UIs on WPF technology for at least the next 15-20 years.
Should you convert to WPF right away, or should you go to the more conventional Windows Forms or ASP.NET Web Forms approach? The answer depends on your application. WPF is a great technology. However, while we write this paper (summer 2006), Microsoft hasn’t released WPF and so far lacks decent WPF tools. We expect that will change during the next year or so. Use WPF if you get a clear advantage from it, either because you want to create a truly innovative UI, or because you want to create a nicely designed and market competitive UI. If all you need is a “.NET UI,” then you can probably wait to transition to WPF-at least for now.
For serious WPF development, you’ll likely need graphic design talent on your team. The same is true for an ASP.NET Web application, but you probably don’t need an artist for a Windows Forms app.
Multithreading
Every user gets frustrated when an application stops responding. Such moments can occur frequently in applications with the capability to run over the Internet as well as a LAN. A professional application must not give the appearance of being “frozen” while loading data or performing processing-intensive operations. From a basic technical standpoint, new processor generations aren’t improving in performance like they used to. For this reason, many modern PCs use “multi-core” setups, with single chips containing two or more processors, but your application can only take advantage of multi-processor systems if you write them to use multi-threaded code. To make sure your application works well on tomorrow’s computer, your application should support multithreading.
Developers can leverage multithreaded programming to make their applications as responsive as possible. Users are getting increasingly accustomed to applications that let them work even while information is being retrieved. For instance, users can write and send e-mails in Microsoft Outlook even when the application is downloading messages. Users can also begin reading a Web page while the browser is busy downloading all the page’s elements (images, videos, etc.).
.NET provides an easy model for allowing developers to add multithreading support to any application, including easy thread creation. More importantly, however, .NET allows developers to create architecture for applications that include multithreading in such a way that the technology is easy and safe to use, even for junior developers. In fact, junior developers often won’t realize that the application they’re working on is multithreaded!
Security
The more people rely on computers, the more secure applications must be. Conversely, the more connected computers are, the less secure they become. Computers with Internet connections are routinely probed by malicious code for potential vulnerabilities. This happens automatically with scripted attacks. So why would someone single out your system for exclusion?
Few companies can afford the losses caused by malicious exploitations of an application. .NET provides capabilities for developers to write and execute more secure applications.
The .NET Framework has a variety of classes allowing developers to write more secure code, with features like role-based security, authentication, authorization, and encryption. The .NET runtime (CLR) provides an extra level of security by managing the code being executed (that’s why .NET code is typically considered managed code), so the code doesn’t perform operations that might compromise the computer.
Strong Typing
.NET languages, such as C# and Visual Basic, are strongly typed, which means that every variable must have a defined type, known at compile time. Strong typing improves code quality by preventing developers from making mistakes (such as declaring a variable a string and assigning a Boolean value to it, or trying to pass an integer to a method that only takes strings). Strongly typed compilers verify type safety during compilation, which results in an elimination of many common run time errors encountered in Visual FoxPro.
Strong-typing also improves the object-oriented programming experience, since anything declared to handle a given type can only store classes that are either (1) of that same type, (2) inherit from that type, or (3) implement the same given interface. Strong-typing also allows for code-static analysis, and it allows for IntelliSense™.
Code-Static Analysis
The typical build process known by every developer involves checking in source code written in your favorite language, compiling that code (which involves pre-processing, grammar link, and raising errors in case problems occur), and then producing a binary file (such as a DLL or EXE file). The build process with code Static Analysis checks the binary file against rules that determine conformance with a variety of guidelines, such as security, performance, naming conventions, interoperability, and maintainability. This process greatly increases the code’s quality.
Unit Test
Automated unit tests are another great way to improve code quality. Using open source frameworks for unit test (such NUnit, or the built-in support in Visual Studio 2005 Team System) provides a simple way to write tests that can be run whenever needed. An automated process is also an option. Unit tests provide a level of safety for making code changes, identifying whether those changes break the application, and if so, where that happens.
Benefits of Moving to Visual Studio
Better IDE / IntelliSense™ - Make sure your developers understand the .NET IDE and how to use it most productively. Visual FoxPro’s IDE has not undergone significant upgrades in a long time. And while the Command window is a great productivity feature you’ll sorely miss in .NET, there are many other .NET tools at the developer’s disposal. The difference between an average developer and a highly productive developer is often quoted at 1:50 and more.
Third-Party Tools - While the pool of third-party tools has begun to dry up in VFP, the number of tools in the .NET space is exploding. Pick up the .NET magazine of your choice (such as our own CoDe Magazine), and you’ll likely find recommendations for free downloadable tools. Of course, there are always commercial offerings as well.
Refactoring - How often do you look at your code and think, “It would have been better to do X, but I’m afraid to change it now”? In .NET, total-reliability refactoring allows you to change your code with the guarantee that it will still work afterward. This allows for changes such as reliable renaming of object members, extraction of an abstract class, extraction of generic methods, and much more.
Larger Team / Community - At its peak, the Visual FoxPro community consisted of tens of thousands of developers. In comparison, the .NET community contains millions of developers. Much of the openness and free exchange of ideas now available in the .NET community was based on studies of the VFP community. Today, sources like GotDotNet.com and CodeProject.com include offerings similar to the experience of UniversalThread.com, though the available pool of content is much larger.
Better IDE experience
Microsoft designed the Visual Studio IDE to help developers create more professional UIs. Distributing and aligning controls on a form is very easy, and the result is a UI that looks better and flows much more smoothly.
The IDE also provides many easy ways to work with visual controls, either by using the Property windows, or a smart tag that offers quick access to the most important aspect of a control.
Third-Party tools
A stunning number of both free and commercial third-party tools are available on the market for .NET. Tools like CodeRush/RefactorPro! and ReSharper greatly improve productivity by enhancing the Visual Studio IDE. Other tools, such as NUnit, TestDriven.NET and TypeMock help improve the quality of code produced. In addition, tools like .NET Reflector and NDepend help developers troubleshoot or learn code.
CodeRush http://www.devexpress.com/Products/NET/IDETools/CodeRush
ReSharper http://www.jetbrains.com/resharper
NUnit
TestDriven.NET http://www.testdriven.net
TypeMock http://www.typemock.com
.NET Reflector http://www.aisto.com/roeder/dotnet
NDepend http://www.ndepend.com
Refactoring
The Visual Studio IDE offers refactoring options that allow developers to easily improve code by, for example, abstracting chunks of code into smaller, more manageable pieces, or safely renaming class members. Even better is if there are unit tests covering the code, since immediate feedback can be seen if a specific refactoring breaks the application.
Larger Team / Community
Resources available for .NET are impressive. We have listed only a tiny sample of those we found most useful. A huge number of Web sites, newsgroups, blogs, podcasts, and videos are available (mostly for free), where developers can learn all sorts of techniques, technologies, tips, and tricks to work with .NET. The community has grown considerably in recent years, primarily because of the number of great conferences, user groups, and free events hosted by Microsoft.
VFP Conversion Resources
http://msdn.microsoft.com/vfoxpro
http://www.MilosSolutionPlatform.com
http://www.universalthread.com
.NET Resources
Podcasts & Videos
Forums
http://forums.microsoft.com/msdn
http://www.universalthread.com
Blogs
http://www.west-wind.com/weblog
http://weblogs.asp.net/scottgu
http://www.markusegger.com/blog
Sample Code
Resources
http://accentient.com/widgets.aspx
Magazines
http://msdn.microsoft.com/msdnmag
Conclusion
Converting a Visual FoxPro project to .NET and SQL Server is not a trivial task. Nevertheless, with the right approach and the right tools, it’s technically feasible. Management must assess the required effort, involved risk, and total cost. You must analyze the conversion’s benefits, in addition to the consequences of not converting. In some cases, you’ll just want to keep what you have and find someone to enhance it.
Every so often, software companies encounter times when the next version of their software is not simply an incremental release. In the history of FoxPro, the moves from FoxBase to FoxPro, and from FoxPro DOS to FoxPro Windows, were such times. Of course, the move from FoxPro to Visual FoxPro was such a time as well. Fortunately, the period between such drastic jumps has increased over the years, with the last big step for VFP developers (the move to Visual FoxPro) having begun in 1995. We expect .NET to be around longer than that.
The trouble with such revolutionary steps is that they require an increased training effort. They also pose the challenge that the talent necessary to assess and avert risk is not readily available. To make matters worse, it’s not enough to know just .NET or VFP to make the move. Instead, the project team must understand both technologies. In addition, staffing requirements for such revolutionary steps are usually beyond the scope of incremental and evolutionary builds.
