Integrating Visual FoxPro with WCF

Modernizing legacy Visual FoxPro applications with service-oriented architecture. A practical approach to consuming WCF services from VFP using COM interoperability and facade patterns.

The Migration Challenge

One of 3Metas' clients had a significant installed base of applications built in Visual FoxPro 7, 8, and 9. Rather than rewriting everything at once, we developed a gradual migration strategy toward a service-oriented architecture (SOA) built with WCF and .NET Framework 3.5.

Strategic Goal

Stop building new functionality in Visual FoxPro while allowing existing applications to benefit from modern business logic and features built with current technology. This required seamless integration between legacy VFP code and new WCF services.

Architecture Overview

The solution uses a COM facade pattern to expose WCF services to Visual FoxPro applications:

1. WCF Service Layer

Build modern WCF services with .NET Framework 3.5 containing business logic and data access

2. COM Facade

Create a COM-visible .NET assembly that wraps WCF service calls and converts generic collections to VFP-compatible arrays

3. VFP Applications

Existing FoxPro code consumes the facade using familiar CREATEOBJECT() syntax

Building the COM Facade

Step 1: Create the Facade Project

Start with a .NET Class Library that references your WCF services. Set up service references using Visual Studio's "Add Service Reference" tool, ensuring generic collections are properly configured.

Step 2: Make the Class COM-Visible

Decorate your facade class with COM interop attributes:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
using ServicioProducto;

namespace ServicesFacade
{
    [ComVisible(true)]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    public class ProductoFacadeVFP
    {
        // Default constructor required for COM
        public ProductoFacadeVFP() {}

        [ComVisible(true)]
        public Color[] GetColores()
        {
            Colores colores = null;

            try
            {
                ServicioProductoClient srv = new ServicioProductoClient();
                colores = srv.GetColores();
                srv.Close();
            }
            catch (Exception ex)
            {
                throw ex;
            }

            // Convert generic collection to array for VFP compatibility
            return colores.ToArray();
        }
    }
}

Key Implementation Points

ComVisible(true): Exposes the class and methods to COM clients
ClassInterface(AutoDual): Enables IntelliSense in VFP
Default Constructor: Required by COM; cannot be overloaded
Array Return Type: Use ToArray() to convert generic collections COM can't handle generics

Deploying to Visual FoxPro

Step 1: Register the COM Assembly

Use RegAsm to register the facade DLL with the CODEBASE parameter:

C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727>RegAsm.exe
  "C:\\3Metas\\Clients\\Cliente\\Proyecto\\ServiceFacade\\ServicesFacade.dll"
  /CODEBASE

Step 2: Deploy Configuration File

WCF's configuration separation from code is crucial. The facade's config file must be renamed and placed correctly:

Critical Configuration Step

Copy the facade's .config file to the same directory as the VFP executable and rename it:

• Development: Place in project directory as yourapp.exe.config
• Production: Place next to executable as yourapp.exe.config
• Most integration errors stem from missing or misnamed config files

Step 3: Consume from VFP

VFP developers can now use familiar syntax to consume WCF services:

LOCAL Colores
LOCAL MyColor as ServiceFacade.ServicioProducto.Color
LOCAL ProductoFacade as ServicesFacade.ProductoFacadeVFP

* Create the facade using familiar VFP syntax
ProductoFacade = CREATEOBJECT("ServicesFacade.ProductoFacadeVFP")
Colores = ProductoFacade.GetColores()

* Work with the data in standard VFP fashion
OPEN DATABASE "C:\\3Metas\\Clients\\Integration\\sampledata" EXCLUSIVE
USE color IN 0 EXCLUSIVE ALIAS tblColor
ZAP

FOR EACH Item IN Colores
    INSERT INTO color (ColorId) VALUES (Item.ColorId)
ENDFOR

Why Not Direct Web Service Consumption?

Alternative: Basic HTTP Binding

VFP can consume web services natively if WCF services are exposed via basicHttpBinding, appearing identical to ASMX web services. However, this approach has limitations:

• VFP may not understand complex .NET business objects
• Other WCF bindings become inaccessible from VFP
• Client didn't want developers learning new web service consumption patterns
• COM objects were already familiar to the development team

Protecting Your Investment

The facade pattern offers future flexibility:

Reusable from .NET

The same facade can be referenced by .NET applications, providing a consistent API across legacy and modern codebases

Type Safety Preserved

By not forcing generic-to-array conversion at the service reference level, .NET clients maintain full type information and LINQ capabilities

Gradual Migration Path

VFP applications benefit from new features immediately while the team plans complete rewrites at their own pace

Benefits of This Approach

Immediate Value: Legacy apps access new functionality without rewrites
Familiar Patterns: VFP developers use COM objects they already understand
Centralized Business Logic: Single source of truth in WCF services
Reduced Risk: Gradual migration rather than big-bang rewrite

Modern Perspective

Note: This article from 2010 demonstrates legacy integration patterns that remain relevant today. While Visual FoxPro is now discontinued, the principles apply to integrating any legacy system with modern services: REST APIs, gRPC, or cloud services. The facade pattern, careful type conversion, and gradual migration strategy remain valid approaches for modernizing enterprise applications. Organizations still maintaining VFP codebases might consider targeting .NET Core/5+ for new services while using similar COM interop techniques for backward compatibility.