Rick Strahl's FoxPro Weblog

What is CORS and how to set it up in West Wind Web Connection

(Rick Strahl) — Mon, 04 Aug 2025 00:38:39 GMT

CORS stands for Cross Origin Resource Sharing and it's a security feature that you need to be aware of if you're building any Http based REST services that are called from a Web browser and that are accessed across multiple domains. This applies if you have a front-end Web site that runs on one domain, and a back-end server that lives on another domain (or IP address). CORS typically kicks in when making script based requests from a browser for these cross domain calls.

The protocol is an odd one, in that it's typically enforced only by Web Browsers, and not in play for most other Http clients like say wwHttp or XMLHttpRequest in FoxPro, or HttpClient in .NET unless you explicitly mimic the Origin and Access-Allow-Request headers that the protocol uses.

When a browser makes a cross-origin fetch() or XMLHttpRequest call from script, it sends a request for CORS headers which the server should respond to with it's own set of response headers. The browser then checks the server’s response for specific CORS headers like Access-Control-Allow-Origin and Access-Control-Allow-Headers. If the headers match the requesting origin and other headers, the browser allows the calling JavaScript to access the response. If it doesn't match the browser doesn't expose the response to the calling JavaScript Http client and throws a script error on the request.

The purpose of CORS is to allow the server to tell the Web Browser whether it is allowed access to the requested Url. Although CORS has to be implemented by the server, CORS is really a Web Browser security feature that only is enforced by Web Browsers, but not other Http clients.

For example the server may want to ensure that requests only come from one or two domains (origins) that are allowed to access the service when called from a browser. Note that CORS doesn't verify or authorize requests - it's merely a protocol feature that sends requesting headers that are confirmed by the server for a follow-on or in-flight request to process.

Web Browser Only Protocol but implemented by the Server

It's an odd protocol because it's only used in Web Browsers, and mostly irrelevant for other Http clients. The reason is that the actual CORS 'security' feature - rejecting a request on invalid or missing CORS data - is implemented by the Web Browser Http client. So it's up to the client to provide this logic and in general only Web Browsers implement CORS security. Other Http never send CORS request nor do they process them or restrict access based on them.

CORS doesn't fire on localhost

It's also easy to forget about CORS during development, because CORS doesn't kick in when running same origin requests. If your Web page and REST Service run on the same domain/IP Address, there's no CORS. During development that's very common, while deployed applications often run on separate servers. Also if you're using Http testing tools like West Wind WebSurge or Postman, CORS doesn't automatically kick in unless you explicitly provide the CORS request headers like Origin and any Access-Allow-Request-xxxx headers. Hence it's easy to forget to test CORS use cases while testing REST applications. Make a point of remembering and/or ensuring you set up specific tests in your Http client request testing suite (you are using that with your services, right? 😄)

The CORS Protocol

CORS is implemented at the Http protocol level via Http headers that are passed from client to server, and back to the client.

It works like this:

The client sends an Origin header and potentially several Access-Allow-Request-xxxx headers
This signals that the server should return a CORS response
The CORS response needs to include at minimum:
- The domain that is allowed access (ie. the current domain)
- The Http Verbs that are allowed
- The Http Headers that are allowed
- Whether security (Authorization, Cookies) is allowed

Depending what type of request you're making CORS data is either made via a separate, pre-flight Http OPTIONS request, or via in-flight headers that are part of a 'normal' request flow.

Pre-flight OPTIONS Request

For most POST, PUT, DELETE, PATCH operations browsers send a pre-flight OPTIONS request to the server which requests a CORS header response. In effect this results in two requests being made to the server by the browser: An OPTIONS request for CORS verification, followed by the original full Http request.

The Http OPTIONS request from client requests only the Http headers for the request and the response returned should contain only the Http headers that a server is expected to return for this request, which includes the CORS headers. The response code should return headers, no data and have a result Status Code 204 No Data although 200 OK with no data also works - the browser doesn't really care about the result code or content, only the headers.

Here's what that looks like:

Figure 1 - A pre-flight OPTIONS CORS request

Note that this is an OPTIONS request that was originally triggered by a POST operation that also requires Authentication in this case. Note that the client sets Access-Control-Request headers to specify what operations it wants to perform which the server response needs to include by adding the corresponding Access-Control-Allow headers. Remember these are typically sent by a Web browser making a cross-origin request via script code.

The server has to respond with headers that include the requested origin, headers and methods. If the CORS headers aren't matched the actual request (ie. the POST request in this case) is never fired and the OPTIONS request fails the original POST operation that initiated this sequence at the client (ie. the fetch() or XMLHttpRequest call).

To clarify the full request flow in this example is:

Browser makes a fetch() request with POST and Authentication
Browser fires OPTIONS request
Server responds with valid CORS response
Browser makes the original POST request
Server responds to POST request

In-flight Request

For simple GET and POST requests that don't include authentication, cookie or custom headers, an Origin header is sent without a separate explicit OPTIONS request and only the single original request is sent. Instead the CORS headers are checked as part of the incoming request and your full response needs to include the CORS headers directly.

Figure 2 - An in-flight CORS request adds CORS headers to the normal request and response headers. Origin is the trigger.

Since in-flight requests don't use a separate request to determine whether the request can execute, it only includes an Origin header to validate that the domain is allowed. Everything else is moot, because the request is already in process. POST operations sometimes send the Access-Control-Request-Headers, but it's not required which means you can't just assume to echo back the Headers that were sent - or not add the CORS headers if you decide to not reject the CORS request.

CORS Failure and Success Responses

If the client makes a CORS request and your server code decides it doesn't want to allow the request to process, there are number of ways to do this.

For failures simply return no content with 403 Forbidden, and don't add any of the CORS headers, which effectively fails the CORS request on the client. Any fetch() or XMLHttpRequest call will then fail in JavaScript code.

For a successful OPTIONS response use 204 No Content, make sure to return the CORS response headers and then exit before processing the rest of the request.

For in-flight non-OPTIONS responses, make sure to add the CORS response headers, and continue processing your request as normal. No need to adjust any special Http Response code.

Beware of Access-Control-Allow-Origin: *

In previous versions of Web Connection (and other server frameworks for that matter) the default generated CORS response for 'all origins allowed' was to specify * for the origin value. Although this is a valid value per spec, in recent years several browsers - namely Safari on Mac and iOS - are refusing to accept any * wildcard values for any of the CORS response headers.

For this reason as of Web Connection 8.5 the templates have changed from the old Access-Control-Allow-Origin: * syntax to explicitly retrieving the Origin header and echoing it back in the outgoing header value. The code at the end of this article shows the new approach that works in this more restricted environment.

CORS in Web Connection

Web Connection doesn't have direct support for CORS as part of the low level Web Connection Web Server connectors, so CORS support has to be implemented at the application level. It's an optional feature and typically only needed for REST projects, although in some rare situations you may also need it if you have individual REST requests as part of an HTML application (rare, but it happens).

When you create a new REST project via the New Project Wizard Web Connection automatically adds CORS support into the generated Process class in OnProcessInit(). The code checks for an Origin header and then displays the appropriate CORS response headers, based on the incoming request. This ensures that valid cross-origin requests are properly acknowledged and allowed by the browser.

The semi generic code to do this lives in your Process class in OnProcessInit():

FUNCTION OnProcessInit
LOCAL lcOrigin, lcRequestHeaders, lcVerb

*** Unrelated
Response.Encoding = "UTF8"
Request.lUtf8Encoding = .T.

*** Add CORS headers to allow cross-site access on REST calls for browser access
lcOrigin = Request.ServerVariables("Http_ORIGIN")

IF !EMPTY(lcOrigin) 
	*** Allow all domains IP addresses effectively
	Response.AppendHeader("Access-Control-Allow-Origin", lcOrigin)  
	Response.AppendHeader("Access-Control-Allow-Methods","POST, GET, DELETE, PUT, OPTIONS")	
	
	lcRequestHeaders = Request.GetExtraHeader("Access-Control-Request-Headers")
	if EMPTY(lcRequestHeaders)
	  lcRequestHeaders = "Content-Type, Authorization" && ,Cookie if you use cookie auth!
	endif
	Response.AppendHeader("Access-Control-Allow-Headers", lcRequestHeaders)
	Response.AppendHeader("Access-Control-Allow-Credentials","true")
ENDIF

lcVerb = Request.GetHttpVerb()
IF (lcVerb == "OPTIONS")
    Response.Status = "204 No Content"
	RETURN .F.  && Stop Processing
ENDIF

*** ... other OnProcessInit() code

The code first checks for the Origin client header, which determines whether the request is cross-site and requires the server to return a CORS response. No Origin means no CORS data is required on the request. So local domain access, or access from a non-Web Browser request won't trigger CORS requests.

When a CORS request comes in here are the items required:

Original Origins

Next this code implements the default Origin behavior which returns the origin requested, which effectively allows access to all domains since we're always returning what the client requests.

If you want to allow only certain domains, you can create some sort of lookup function or even a hard code a list of domains to allow. If a CORS request fails you can return a 403 Forbidden status - and not return the CORS headers.

Here's what that looks like:

IF !EMPTY(lcOrigin) 
    IF !THIS.CheckForValidOrigin(lcOrigin)
       Response.Status = "403 Forbidden"
       RETURN .F.
    ENDIF 
    
	Response.AppendHeader("Access-Control-Allow-Origin", lcOrigin)  
    ...
ENDIF

Methods

You need to specify the allowed methods when OPTIONS requests are made. In OPTIONS requests the client will send Access-Control-Request-Methods which you can echo back. Not though that this value is not present in inflight requests so it's better to use a fixed set of Http Verbs that you are planning to use in your project.

Easiest just to return all the methods your app supports, but you could also return the specific verb being requested.

Response.AppendHeader("Access-Control-Allow-Methods","POST, GET, DELETE, PUT, OPTIONS")

Note that in an OPTIONS command you need to include OPTIONS plus Access-Control-Request-Methods rather than just using Request.GetHttpVerb().

Headers

This one is a little tricky since you may not know what headers you need to support for all requests. OPTIONS requests provide an explicit Access-Control_Request-Header value that you can echo back, but again there's no guarantee that this value exists so you want to make sure you have a default value ready using this logic:

lcRequestHeaders = Request.GetExtraHeader("Access-Control-Request-Headers")
IF EMPTY(lcRequestHeaders)
  lcRequestHeaders = "Content-Type, Authorization" && ,Cookie if you use cookie auth or Sessions!
ENDIF

The tricky bit here is that you need to provide all custom headers that you might send. While that may seem easy for individual requests, it's more difficult to figure out exactly what's needed for every request in an application and distill that down to a single set of headers. Hence you'll want to use the requested headers if available. If you have custom headers it'll always trigger an OPTIONS request, so in that case the Allow-Control-Request-Headers should be sent with the incoming request and that's what you should return in your CORS header response.

Allow Credentials

If your app has any authentication you'll want to set this value to true. This is needed if you have Authorization or Cookie headers.

Kind of silly that this is required since the headers should be able to determine whether this is required.

Summary

CORS is a clunky protocol and when you first look at it, it doesn't seem to be very effective at providing any security at all. However, for browsers it is useful in ensuring that errand Web browsers can't spoof requests from an embedded iframe for example. The server can explicitly check valid source domains and refuse to serve requests if the list of client domains is not met. However, that does not negate the problem because non-Web Browser clients can call your server any way they want - including potentially spoofed origin domains.

The good news is that it's easy to implement CORS for your REST services in Web Connection. There's only a little bit of code required, and in can be placed into a single entry point in OnProcessInit() in one place. If you're creating new REST projects, Web Connection automatically provides the CORS code in the generated process class and if you have existing code you can easily copy in the code from this article...

this post created and published with the Markdown Monster Editor

Web Connection 8.4 Release Post

(Rick Strahl) — Wed, 23 Jul 2025 01:32:21 GMT

Hi all,

I've released Web Connection 8.4 which is a minor maintenance release of the FoxPro Web and Service Development framework. The primary reason for this release are several small bug fixes that might be impacting some of you if you are:

Using wwUserSecurity Authentication (especially in Virtual Folders)
You're using Multipart Form Uploads via wwHttp

If that's you and you're using v8.1-8.3, you'll probably want to update to the latest version as soon as possible.

There are also a couple of nice enhancements in wwDotnetBridge, and a new documentation viewer offline application.

Bug Fixes

Let's start with the important bug fixes because they are the main reason for this release.

In the last 8.2-8.3 a regression error was introduced that in certain situations would not properly set the wwUserSecurity related authentication Session cookie. Specifically this can be a problem in scenarios where you're using a non-root virtual folder in your Web application.

I'm not quite sure why this particular error occurred only with virtual folders since Web Connection cookies are always set on the domain root, but for some reason cookies set when running under the virtual in some cases would not be set properly. The issue basically was that a session Id was present but for some reason the session was not recovered and so a new session key gets generated on each check attempt which effectively results in a successful login that lasts only for the current requests. Oddly this only occurs in virtuals and then more likely on nested virtuals (for me it happened in the Web Connection Weblog specifically).

It's fixed now where the code now explicitly generates a new cookie on login rather than checking for an existing cookie to update.

Fix: wwHttp Multipart Form Data Content Type not getting set

This issue is another regression that cropped up from the recent work to support greater than 16mb uploads and downloads. Essentially, the Content Type parameter on AddPostKey() was not being passed through in to the request. It does work for the newly added AddPostFile() but if you're using older code that uses AddPostKey() to upload files the content type was not being appended.

In the process of fixing this bug, I also cleaned up the signature to the AddPostFile() method. The method initially had inherited the same signature as AddPostKey() but there were several parameters that are superfluous for uploading files, so the signature was adjusted for more logical flow.

The change to AddPostKey is a potential breaking change if you were using the method since the order of parameters has changed.

Missing JsonService Variable in wwRestProcess Process Methods

Another regression bug relates to wwRestService and the use of the intrinsic JsonService variable that is passed as a shortcut for THIS.oJsonService into a REST Process method. The error was due a missing PRIVATE scope assignment at the top of the processing pipeline in RouteRequest().

This has been fixed.

New and Improved Features

Not much to report in this update but there are few.

wwDotnetBridge: Unblock all DLLs loaded

The classic .NET Framework still uses Windows Vista Style zoning security by default and so respects the custom blocking attributes that are added to binary files downloaded from the Internet (including files embedded in Zip or 7zip files when unpacked), media devices or from non-local domain drives. Files from those sources get implicitly marked by Windows as 'blocked'.

wwDotnetBridge has for some time explicitly removed blocks on wwDotnetBridge.dll which is the initially loaded Dll that loads the runtime. In most cases that's enough, but I've recently run into cases where other DLLs being loaded were also affected and failed when calling loBridge.LoadAssembly(). For this reason, wwDotnetBridge now also removes blocks from any assembly loaded via LoadAssembly() before loading.

This should improve issues with blocked DLL loading significantly, but you may still run into problems if the DLLs loaded load other DLLs implicitly. In that case you can explicitly load those assemblies using LoadAssembly() (starting with the most deeply nested dependency first), or you can manually unblock files as described in this help topic.

New Offline Documentation Viewer

For years several people here - looking at you Tore - have hounded me to provide offline documentation again as we used some time ago. In the past I created a very large PDF document which was problematic to create as I used Word Automation to import from Html and then Print to Pdf. That process was very brittle and took a really long time to run and often would randomly fail.

Well, recently I switched the documentation over to a new documentation system I've been building called Documentation Monster, which is a Help Builder like system built ontop of my popular Markdown Monster editor.

As part of that tool there's a new option to create a self contained documentation viewer application that can be used to browse the online documentation offline.

Here's what that looks like for Web Connection:

All the functionality of the Web site is available in the offline Viewer so you get all the same docs - offline.

The big benefit from my end is that's easy and fast to build so this documentation is much easier to keep in sync with the online documentation.

The tool produces a self contained EXE that itself is very small. The size of the EXE is determined primarily by the size of the documentation which is embedded inside of the Exe and unpacked when run. That said the Web Connection file is still in the 20mb range zipped due to the huge amount of content and media. The Exe has no dependencies as it runs on the built-in .NET framework.

You can check it out from here:

Download the Web Connection Documentation Offline Viewer

Summary

Overall this is a very small release that's primarily been released for the bug fixes (which have been avaiable for a while in the Experimental Updates Zip file as soon as they were discovered and fixed).

I would recommend updating to the latest version if you are on 8.1-8.3.

Creating and Debugging .NET Assemblies for wwDotnetBridge and Visual FoxPro

(Rick Strahl) — Fri, 23 May 2025 03:49:41 GMT

If you're using wwDotnetBridge with FoxPro it's quite likely that at some point you'll want to create your own .NET Dlls that interface with external .NET code. While wwDotnetBridge allows you to interface with .NET directly, the code you have to write can be quite tedious because for many things you have explicitly reference the intrinsic methods like InvokeMethod(), SetProperty(), GetProperty() to interact with data that is not compatible over straight COM. While most of these things can be done from FoxPro, the process of doing so is often verbose and in some cases requires multiple objects to be passed around. These intrinsic type scenarios are also relatively slow - compared to native code that is directly executed from .NET. At minimum every .NET call involves a COM call between FoxPro and .NET and when using the Intrinsic methods using Reflection in .NET. It's not horribly slow but compared to native .NET code directly called from .NET it's definitely slower.

Additionally using .NET natively gives you much easier discovery of what's available via the .NET IDE tools that provide rich Intellisense, code completion, CoPilot, Refactoring and easy code navigation. All of this adds up to a richer experience.

Now if you're making only one or two calls into a .NET library from FoxPro it's probably not worth creating a separate .NET component. But if you're making a lot of calls back and forth or the code is performance sensitive, then it may very well be worth your time to create a wrapper .NET compoent that you make one or two consolidated calls to and which then handles many .NET operations or entire component functionality.

I am a big fan of building wrapper components in .NET where you can pass a few key values of input to the wrapper from FoxPro using COM optimized types, and the wrapper then does the brunt of work using native .NET code. If you look at most West Wind components like wwSmtp, wwFtpClient, MarkdownParser, this is exactly how those components are built - there's a .NET class that exposes most of the functionality with a few very focused method calls that combine hundreds of .NET calls and a FoxPro front end abstraction that calls into the wrapper. This is by far my preferred way of exposing functionality from .NET libraries to FoxPro as it optimizes each platform for what it does best.

I know many of you old FoxPro dogs want to do everything in FoxPro, but one of the big advantages of wwDotnetBridge is that it lets you bridge the gap between FoxPro and .NET. It provides an easy on-ramp for experimenting and integrating .NET code into your own applications one piece of code at a time. Whether you implement a single .NET method that you call from FoxPro, a full class, or a whole complex API of components or business objects - you can choose your own pace. Because you're calling a library you can choose how modular you want to go. It's a practical way to create small islands of functionality outside of FoxPro that still can easily integrate with your FoxPro application transparently.

Creating your own .NET Components

So when you build a .NET component to interface with, you're going to create a Library Project in .NET. A .NET Class library is essentially library of potentially unrelated classes that doesn't have a 'startup' class. A library is a project without an entry point: It's not a Desktop or Web or Console project, but it's just one or more .NET types (classes, structs, enums etc.) that can be called directly from .NET or... from FoxPro using wwDotnetBridge.

Any .NET class library that you create can be instantiated and called via wwDotnetBridge. IOW - you create a class in .NET, put it somewhere FoxPro can find it and call it with wwDotnetBridge:

do wwDotnetBridge  && load lib
loBridge = GetwwDotnetBridge()

llResult = loBridge.LoadAssembly("bin\MyFirstLibrary.dll")
? loBridge.cErrorMsg  && if there's an error and llResult is false

loPerson = loBridge.CreateInstance("MyFirstLibrary.Person")
loPerson.Firstname = "Rick"
loPerson.Lastname = "Strahl"
loPerson.Address = loBridge.CreateInstance("MyFirstLibrary.Address")
loPerson.Address.Street = "999 Emergency"
loPerson.Address.PostalCode = "97000"
loPerson.Entered = DATETIME()
loPerson.Save()

To create a minimal .NET project literally takes two files: A project file and a source code file that contains one or more classes that can be called. If you need more classes or components you can add them to the same file or create new classes. The new .NET project system automatically picks up and compiles all source files it finds so it's easy to add functionality.

There are a number of ways to create a new project, but due to the fact that recent versions of Visual Studio and the dotnet new CLI don't include templates for new .NET Framework (net4.x) projects.

While you can use the tooling, but my preferred way of doing this is just creating the project file and the main class by hand (or copying an existing project template from here).

There are two reasons for this :

.NET Tools (Visual Studio and the dotnet CLI) don't support creating new .NET 4.x projects
It's easy to copy a couple of files to disk

Although neither Visual Studio, the dotnet command line or VS Code support creating .NET Framework projects, you can definitely build them once created. They are just hiding .NET Framework projects because Microsoft is trying to push everyone to .NET Core.

However, I highly recommend that you create .NET Framework (.NET 4.x) projects rather than .NET Core projects for your components unless you have a pressing need for .NET Core features or you need to interface with another library that does not support .NET 4.x or .NET Standard 2.0 which both can be used with the built-in .NET Framework.

The reason is simply that the .NET Framework is built-into Windows so there's nothing to install. You can create a .NET Framework project compile and run without any other requirements other than the tiny DLL created (plus any dependent assemblies your component references). .NET Core on the other hand requires that a compatible runtime is installed, which means you have to make sure that your application checks and deploys the right runtime. There's no such requirement for .NET Framework.

If you build for .NET Framework chances are that you can also move the code to .NET Core easily by adding a second target, so this is not a 1-way street or you can multi-target and actually support both. Difference between them are slight especially if you stick to core functionality.

Creating a new Project 'by hand'

There are a number of ways of creating a .NET project, but here's what I do:

Create a new folder
Open Visual Studio Code in that folder initially (or any other editor)
Create the following two Files in there (Project and first component)
Use the command line tools to build and run to test the component

I do this even if I have Visual Studio installed. Why? As mentioned neither Visual Studio or the dotnet new CLI has support for .NET framework. While you can create a new project for netstandard2.0 which is close to what you need - you need to make a few small changes to the project. So rather than screw around with this changing template and remove things that don't work, I use either a template from disk or manually create the files and copy in the small bits of project and initial class code.

Start by creating creating a new folder for your project and opening an editor there:

# create and goto  directory
cd D:\wwapps\Conf\wwDotnetBridgeRevisited\Dotnet\FirstLibrary

# Open VS Code in folder mode
code .

Create two files:

FirstProject.csproj
Person.cs

Here's the project:

<!-- FirstLibrary.csproj -->
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>    
    <TargetFramework>net472</TargetFramework>    

    <!-- Optional: Output to a specific folder. Relative or absolute -->    
    <OutputPath>..\..\bin</OutputPath>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
   
  </PropertyGroup>
</Project>

This sets the target .NET 4.72 or later and puts the output DLL into the specified folder. The folder is optional - if you don't specify it goes into a deep folder hierarchy below the project. Typically you don't want this.

Personally I like to put all my .NET assemblies either into my application's root folder (if there's only one) or .\BinSupport folder below it for many Dlls.

Next you need to create at least a single .cs source file with a class in it. I'll create the Person and Address classes I used in the previous example here:

using System;
using System.Collections.Generic;

namespace FirstLibrary
{
    public class Person
    {
        public string Firstname {get; set; }
        
        public string Lastname {get; set; }
        
        public DateTime Entered {get; set; }  = DateTime.Now;

        public Address Address {get; set;} = new Address();
        
        public bool Save()
        {
            // do whatever to save here
            return true;
        }

        public override string ToString()
        {
            return Firstname + " " + Lastname ?? string.Empty;
        }
    }

    public class Address
    {
        public string Street {get; set; }
        public string City {get; set; }
        public string State {get; set; }
        public string Zip  {get; set; }

        public override string ToString()
        {
            return Street + "\r\n" + City + "\r\n" + State + " " + Zip;
        }
    }
}

Next we need to build the project. You can open a Terminal (Powershell here) either in Visual Studio Code or directly on the command line in the project folder and then build the project.

dotnet build FirstLibrary.csproj

This builds the project into the output folder which happens to live below my FoxPro project folder as ,\bin.

I can then call the and the component from FoxPro with:

CLEAR
do wwDotnetBridge  && load lib
loBridge = GetwwDotnetBridge()

llResult = loBridge.LoadAssembly(".\bin\FirstLibrary.dll")
? loBridge.cErrorMsg  && if there's an error and llResult is false

loPerson = loBridge.CreateInstance("FirstLibrary.Person")
loPerson.Firstname = "Rick"
loPerson.Lastname = "Strahl"
loPerson.Address = loBridge.CreateInstance("FirstLibrary.Address")
loPerson.Address.Street = "999 Emergency"
loPerson.Address.City = "AnyTown"
loPerson.Address.PostalCode = "97000"
loPerson.Entered = DATETIME()
loPerson.Save()

? loPerson.ToString()

Altogether it looks like this:

The above does:

Builds the project and compiles into the app folder (....\bin)
Open FoxPro
Runs the test.prg file

Cool it works.

Shutting down Visual FoxPro to Unload .NET Assembly

.NET and any components cannot be unloaded once loaded, so in order to update the DLL you have to shut down the host process, which in this case is Visual FoxPro (or your app EXE).

If you need to make any changes to the DLL code, you need to:

Shut down Visual FoxPro (or EXE)
Rebuild the .NET project
Restart Visual FoxPro

To make this cycle a little easier I tend to create a small Powershell (or Command) script that I can run from the terminal in the project folder:

dotnet build .\FirstLibrary.csproj

if ($LASTEXITCODE -ne 0) {
    exit
}

$startdir = $pwd

Set-Location ..\..
& D:\programs\vfp9\vfp9.exe
Set-Location $startdir

This script handles building the project and launching VFP. It doesn't shut down FoxPro first - you'll have to do that manually, but building and starting up FoxPro is handled to make the launch a bit quicker than manually fumbling around to launch VFP in the right place.

All of this works fine and it's pretty low impact so far. No need to install anything beyond the .NET SDK and VS Code (or your editor of choice).

But things could be a little more integrated. And that's where Visual Studio comes in.

If you want:

A smoother build and run cycle
Ability to debug your DLL

then using Visual Studio is a worthwhile upgrade to the dev process.

Opening the Project in Visual Studio

Although I used Visual Studio Code (or no editor/IDE at all) to create the project originally, I can now also open this project in Visual Studio by opening the FirstProject.csproj from Explorer and selecting Visual Studio to open:

Figure 4 - Opening the project in Visual Studio lets you build and run more interactively

From here you can build (right click Build or Rebuild) or you can Debug the project with the debugger using the green run button.

In order for that to work we need one more file to configure how to 'launch' our Dll. Create a launchsettings.json file that contains the startup options (you can also do this from Properties ? Debug ? Open Debug Launch Profiles Ui but it's easier to create the file manually):

{
  "profiles": {
    "VFP (Debug)": {
      "commandName": "Executable",
      "executablePath": "d:\\programs\\vfp9\\vfp9.exe",    
      "workingDirectory": "D:\\wwapps\\Conf\\wwDotnetBridgeRevisited\\Dotnet\\FirstLibrary"
    }
  }
}

This file specifies the path to the Visual FoxPro IDE (or if you prefer your application executable) and the folder that you want to start it in, which is your FoxPro project folder. From there you can then run your application or test program as I did in the example above.

Debugging

For debugging it's important to understand that you are driving the debugging process through Visual Studio/.NET rather than through your FoxPro application. Visual Studio launches FoxPro or your application, and you then run the code that eventually hits the .NET code that you have a breakpoint on. But Visual Studio is in control of the process and FoxPro is just the target that actually calls into .NET code you are debugging.

Note that you can debug your own code .NET readily enough, but in most cases you can't debug external, system or third party .NET code unless debug information (.pdb) file is provided by the vendor.

So, with the Launch profile configured we can now run the application in Debug mode. When running in Debug mode you can now set breakpoints in your code, and the debugger then stops on those breakpoints:

Figure 5 - Stopped on a breakpoint in the Visual Studio Debugger.

When on a breakpoint you can examine values using the Locals and Watch windows, but you can also hover over any active values or properties to display their values. From there you can continue to step over code using all the standard over, into, out step operations you're familiar with.

Another nice feature: The debugger supports hot reload, which means you can make changes to some code while the app is running. If you've changed code that's already executed, you can move the execution pointer back to before the edit location and the code runs again with the newly compiled code. This can be a huge time saver when you're fixing code and trying to get it to work correctly.

This example doesn't use any external libraries, but if you were interfacing with other libraries things work exactly the same. Again - debugging is limited to your own code in most cases.

And that's it! With this you have all you need to build, run and debug your .NET components.

VS Code also supports debugging and there's also a commandline debugger available. However, those debuggers only work with .NET Core and even then they don't work very well with an external process to attach to.

Summary

If you're using wwDotnetBridge it's a good idea to take advantage of .NET as best as you can by avoiding excessive .NET code written from FoxPro code using wwDotnetBridge functions. If you're writing copious amounts of wwDotnetBridge code in FoxPro it's time to think about offloading that code into a .NET class or component that you can abstract and call from FoxPro with a simpler and much less chatty interface.

Building .NET libraries is much easier than it used to be in days past, either using the no-IDE command line tooling, or if you want the IDE experience with a somewhat less intrusive Visual Studio installation. The tooling is drastically better and less intrusive to install than it used to be a few years ago.

By using .NET code for more complex tasks you can make development of your code easier, and also improve performance by avoiding a chatty COM interop interface calls for every member access. While performance of wwDotnetBridge both with native COM calls and Reflection intrinsic method calls, doing those calls directly in .NET is still considerably faster.

I highly recommend this approach on anything that exceeds a few lines of .NET code that you need to call from FoxPro. .NET code is compact and you can cram many different components into a single tiny DLL that you can ship with your application with little to no overhead. And since you're using wwDotnetBridge already anyway having one extra DLL is not an issue.

Finally, by offloading some processing into .NET you have a chance to learn something new at your own pace. Because wwDotnetBridge interfaces deal with components you can create components large and small to move small chunks of your application to .NET that you can perhaps use in the future in other projects or if you decide to migrate in the future.

Resources

FoxPro Running on a Windows ARM Device

(Rick Strahl) — Thu, 07 Nov 2024 06:42:14 GMT

I recently picked up a Windows ARM 'Co-Pilot' capable laptop and took it for a spin running my typical spread of Windows applications and tools. I also checked out how well it works with FoxPro - here's what I found.

Web Connection 8.1 Release Post

(Rick Strahl) — Mon, 14 Oct 2024 19:29:02 GMT

Web Connection 8.1 is out. This is a small maintenance release, but it does include a few significant updates.

Making Web Connection Work with Response Output Greater than 16mb

(Rick Strahl) — Mon, 30 Sep 2024 22:30:22 GMT

Web Connection in the past has not supported > 16mb direct output via plain string based output, due to FoxPro's 16mb string limit. 16mb is a lot of text and while I generally don't recommend returning that much data as part of non-file request (which does support larger files) it's a feature request that comes up from time to time as people overrun the limit. During last weekend's SW Fox conference I heard about this issue again in a session and decided to address it once and for all and this posts describes the change and how it's implemented.

wwDotnetBridge Revisited: An updated look at FoxPro .NET Interop

(Rick Strahl) — Mon, 23 Sep 2024 04:34:21 GMT

In this very long white paper for the Southwest Fox conference, I discuss the basics of wwDotnetBridge and then demonstrate a variety of functionality with 10 examples. We'll see basic usage, how to wrap classes in FoxPro and .NET, how to use a variety of .NET 3rd party libraries, how to handle .NET events and how to make Task based async calls.

West Wind Web Connection 8.0 Release Notes

(Rick Strahl) — Tue, 25 Jun 2024 21:05:49 GMT

Web Connection 8.0 is here and this is the official release post for this new version.

West Wind Client Tools 8.0 Release Notes

(Rick Strahl) — Thu, 30 May 2024 17:19:04 GMT

West Wind Client Tools 8.0 has released as a major version rollup release. Here's all that's new and fixed.

wwDotnetBridge and Loading Native Dependencies for .NET Assemblies

(Rick Strahl) — Sat, 23 Mar 2024 20:12:11 GMT

If you're using a .NET component with wwDotnetBridge or plain COM Interop that has a native dependency on non-.NET DLLs, you need to be careful to ensure that the native libraries can be found. In this post I describe how .NET assembly loading works and how external native dependencies are resolved in .NET and subsequently how you have to deal with them in your FoxPro applications.

Rick Strahl's FoxPro Weblog

What is CORS and how to set it up in West Wind Web Connection

Web Browser Only Protocol but implemented by the Server

CORS doesn't fire on localhost

The CORS Protocol

Pre-flight OPTIONS Request

In-flight Request

CORS Failure and Success Responses

Beware of Access-Control-Allow-Origin: *

CORS in Web Connection

Original Origins

Methods

Headers

Allow Credentials

Summary

Web Connection 8.4 Release Post

Bug Fixes

Fix User Authentication Session Cookie Bug

Fix: wwHttp Multipart Form Data Content Type not getting set

Missing JsonService Variable in wwRestProcess Process Methods

New and Improved Features

wwDotnetBridge: Unblock all DLLs loaded

New Offline Documentation Viewer

Summary

Creating and Debugging .NET Assemblies for wwDotnetBridge and Visual FoxPro

Creating your own .NET Components

Creating a new Project 'by hand'

Shutting down Visual FoxPro to Unload .NET Assembly

Opening the Project in Visual Studio

Debugging

Summary

Resources

FoxPro Running on a Windows ARM Device

Web Connection 8.1 Release Post

Making Web Connection Work with Response Output Greater than 16mb

wwDotnetBridge Revisited: An updated look at FoxPro .NET Interop

West Wind Web Connection 8.0 Release Notes

West Wind Client Tools 8.0 Release Notes

wwDotnetBridge and Loading Native Dependencies for .NET Assemblies