Integrating Visual FoxPro with Windows Communication Foundation

One of the clients of 3Metas has a very large installed base of applications built in Visual Fox Pro 7, 8 and 9. Over the last few months we have worked together to develop a strategy for migrating these applications toward a service-oriented architecture (SOA) built with WCF and the .Net Framework 3.5.

One of the key aspects of a process like this is to avoid, as much as possible, continuing to build functionality in Visual Fox Pro (VFP), so the first step of the strategy consists of integrating VFP with Windows Communication Foundation (WCF) services, in such a way that the current applications benefit from the improvements in business logic or from new functionality built with the latest available technology.

1. The first thing that must be done is to build a WCF service, which I will not go into in depth.

2. In our case, once we had the service built, we built a facade for its use from VFP.

3. In this facade we set up the references to the services using the Visual Studio tool; there we verify the type of conversion that will be performed on the generic collections. Since we want to protect the client's investment in this project, this facade must be usable from VFP, but also from applications developed with .Net today and in the future.

4. We create a class that will be visible to COM from VFP and that will be the facade for this tool

5. This class must be decorated as COM visible [ComVisible(true)] and, to ensure the IntelliSense options, we also add the interface generation decoration [ClassInterface(ClassInterfaceType.AutoDual)]

6. Although Visual Studio 2008 (VS2008) creates the constructor by default, we prefer to be sure, so we add the constructor. Keep in mind here that the constructor cannot be overloaded or receive parameters, to avoid problems in COM

7. Then we create the methods that will be consumed by VFP and decorate them as visible to COM [ComVisible(true)].

8. In our case, the WCF service methods return generic collections of specific types, for example the collection of colors of the Color entity: [CollectionDataContract(Name = “Colores”, Namespace =”http://myDomain.com/Data/2010/01″)] public class Colores: Collection<ColorEntity> {}, so that these methods can be consumed from VFP, and taking into account COM's restriction on handling generics, the method is modified so that it does not return the collection but instead returns an array of objects, which is something that VFP can handle. The ability to convert the generic collection into an array was added with LINQ, so the reference to LINQ must be established in the project and the class. In the end it should look something like this:

 1: using System;

 2: using System.Collections.Generic;

 3: using System.Linq;

 4: using System.Text;

 5: using System.Runtime.InteropServices;

 6: using ServicioProducto;

 7: 

 8: namespace ServicesFacade

 9: {

 10: 

 11:     [ComVisible(true)]

 12:     [ClassInterface(ClassInterfaceType.AutoDual)]

 13:     public class ProductoFacadeVFP

 14:     {

 15:         //default constructor

 16:         public ProductoFacadeVFP() {}

 17: 

 18:         /// <summary> 

 19:         /// Metodo trae los colores del Sistema

 20:         /// </summary>

 21:         /// <returns></returns>

 22:         [ComVisible(true)]

 23:         public Color[] GetColores()

 24:         {

 25:             Colores colores = null;

 26: 

 27:             try

 28:             {

 29:                 ServicioProductoClient srv = new ServicioProductoClient();

 30:                 colores = srv.GetColores();

 31:                 srv.Close();

 32:             }

 33:             catch (Exception ex)

 34:             {

 35:                 throw ex;

 36:             }

 37: 

 38:             return colores.ToArray();

 39:         }

 40:      }

 41: }

9. When compiling this project you will obtain a DLL and a configuration file that corresponds to how the communication with the service will be established (Address and Bindings); these two files are the ones that must be delivered to the VFP developers so they can consume the services.

Once the phase of preparing and building the services and their facade is complete, the VFP developers can now integrate these components into their applications. To do so, the following activities must be carried out:

1. Register the COM interface of the services facade using the command regasm; ideally, the CODEBASE parameter should be used. The instruction would be something like this if run from the .Net Framework 2.0 directory: C:WINDOWSMicrosoft.NETFrameworkv2.0.50727>RegAsm.exe “C:3MetasClientsClienteProyectoServiceFacade ServicesFacade.dll” /CODEBASE

2. One of the most important aspects of WCF is the separation of the service configuration from the code: the address and the binding of the service are defined in the configuration file, and this configuration file was generated when compiling the facade. For each project in which the facade is going to be used, the service configuration file must be copied to the same path as the VFP application's executable or, for debugging, to the path where the project resides; this file must be renamed with the name of the VFP application and the .config extension. In our case it ends up something like this: aplicaciondelcliente.exe.config. Many of the errors that can arise when using the facade have to do with the fact that the application cannot find the configuration file.

3. Once the facade's COM interface is registered and the service configuration file is correctly renamed and located, everything is ready for the developer to use the services from VFP. You only need to use the CREATEOBJECT method with the name of the facade class. For example:

 1: LOCAL Colores

 2: LOCAL MyColor as ServiceFacade.ServicioProducto.Color

 3: LOCAL ProductoFacade as ServicesFacade.ProductoFacadeVFP

 4: 

 5: ProductoFacade = CREATEOBJECT("ServicesFacade.ProductoFacadeVFP")

 6: Colores = ProductoFacade.GetColores()

 7: 

 8: OPEN DATABASE "C:3MetasClientsIntegrationsampledata" EXCLUSIVE

 9: USE color IN 0 EXCLUSIVE ALIAS tblColor

 10: ZAP

 11: 

 12: FOR EACH Item IN Colores

 13:     INSERT INTO color (ColorId) VALUES (Item.ColorId)

 14: ENDFOR

Done: the VFP development team is now consuming WCF services.

Juan Peláez

CTO

3Metas Corp.

Important clarifications:

· With Visual Fox Pro you can consume Web services, so if the WCF services are exposed with a basic HTTP binding, the WCF service looks exactly like a web service and can therefore be consumed from FoxPro without problems. However, from a technical perspective it can run into problems with business objects that VFP does not understand, or if the WCF service is exposed through another binding, which would make it impossible to consume from native VFP. In our case, the applications were not built consuming web services and the client did not want to invest developer time in having them learn to consume web services from VFP, so it made sense for them to consume COM objects, which are familiar to them.

· When creating the facade project, the conversion of the generic collections into arrays (ARRAYS) could be configured through VS2008; however, that would make the facade lose data types that could be used by .Net clients

References:

http://www.dotnet247.com/247reference/msgs/15/75021.aspx
http://www.west-wind.com/presentations/VfpDotNetInterop/DotNetFromVFP.asp
http://www.west-wind.com/presentations/dotnetfromVfp/DotNetFromVfp_ComplexObjects.asp
http://blogs.msdn.com/calvin_hsia/archive/2005/09/02/460206.aspx

Advertising

Migrating Visual FoxPro applications to .NET? Trying to establish a policy or a development process for your legacy applications? Contact us at sales@3metas.com; our team has the experience and the skills needed to achieve successful results.