Rick Strahl's FoxPro and Web Connection Web Log
White Papers | Products | Message Board | News |

Route Web Connection Scripts, Templates and Pages to a single Process Class

No comments
Sunday, January 15, 2017, 2:51:44 PM

West Wind Web Connection supports a number of different 'frameworks' for generating HTML. There are two styles of MVC (Model View Controller) renderers and an ASP.NET like Forms based interface for creating rich FoxPro code based HTML pages.

These engines are available:

  • Web Connection Scripts (wcs by default)
    HTML templates that compile into FoxPro PRG files and are executed as code

  • Templates
    Simple templates that work well with embedded expressions and self contained code blocks that are evaluated on the fly (ie. no compilation).

  • Web Control Framework Pages
    These are ASP.NET style pages that use an object based approach to describing controls on a page.

Both Scripts and Templates work for MVC style applications where you have controller code in a class method, and the template/script is the view that displays the model data you accumulated in the controller code to display in the script or template.

Web Control Framework pages are more complex, compiling HTML controls into component classes that are coordinated and rendered by the page framework.

Only one Default nPageScriptMode

When you set up a new Web Connection process class that process class can associate with a default nPageScriptMode:

  • 1 - Template
  • 2 - Web Control Framework
  • 3 - Script

The default is 3 - Script.

The default determines what happens when you access a page like NonMethodPage.wwd for example, where there is no matching method in the Process class. If there is no NonMethodPage method in the class, Web Connection falls back to the default nPageScriptMode to decide what to do with the script. In this case, wwd will be passed to the default nPageScriptMode which is 3 - Script which compiles the script into a small PRG/FXP and it runs.

Handling more than one nPageScriptMode

So I just said that there's only one default, right? And that is so, but... you can actually tweak the behavior by explicitly setting the nPageScriptMode based on parsing rules in your code.

If I wanted to have multiple script maps for a single process method I might set up wwd, wwds, wwdx extensions for templates, scripts and pages respectively.

I then have to make sure I route all of these extensions in my MyServer::Process():

CASE lcExtension == "WWD" OR lcExtension == "WWDS" OR lcExtension == "WWDX"
    DO wwDemo with THIS

actually this is enough if SET EXACT OFF as it is by default:

CASE lcExtension = "WWD"
    DO wwDemo with THIS

this makes sure all requests with these extensions are routed to my process class.

In the process class I can then handle the extension routing in the OnProcessInit():

FUNCTION OnProcessInit()

* ... other init code

lcExt = UPPER(JUSTEXT(this.oRequest.GetPhysicalPath()))
THIS.nPageScriptMode = 3
   CASE lcExt == "WWD"
      this.nPageScriptMode = 1
   CASE lcExt == "WWDS"
      this.nPageScriptMode = 3
   CASE lcExt == "WWDX"
      this.nPageScriptMode = 2

Because OnProcessInit() fires early in the process pipeline you can change the page scriptmode which is used in wwProcess::RouteRequest() to find the right handler. Checked this out and it works great using a single process class to route requests for each extension to the appropriate handler.

And voila - you can now handle wwd pages as templates, wwds pages as scripts and wwdx pages as Web Control Framework pages.

You can make the logic more complex as well and look at other parts of the request. Perhaps extensionless URLs or query strings etc. - you have full access to the Request object to do as you please to figure out what gets routed where.

It's a cool little trick for your Web Connection applications.

this post created with Markdown Monster

Visual Studio Gets Support for FoxPro Files

Wednesday, November 16, 2016, 2:26:15 PM

Visual Studio 2015 now has support for FoxPro files by way of a very cool add-in from Mads Kristensen. Mads is a a Program Manager on the Visual Studio Tools team and the prime driver behind extensions for ASP.NET tooling and he has created a cool extension that can take existing Textmate style syntax files and render them as syntax highlighted documents. Thanks to Matt Slay who a while back created a Sublime Text FoxPro language extension, Mads was able to add FoxPro as a language to the extension language pack.

End result: You can now view and edit FoxPro files with syntax coloring in Visual Studio natively. Keep in mind this basic syntax coloring support, not a full featured editor with auto-complete. Just the basics...

Here's what this looks like:

You can find out more and install the extension from here:

or use the Visual Studio Extension Manager to add it directly from within Visual Studio.

You'll also want to install the File Icons extension to show appropriate icons for your FoxPro files:


It's nice to have native support for FoxPro right in Visual Studio, so you can open and edit FoxPro files right from the Visual Studio project.

This works great when working with Web Connection, so that you can quickly open PRG files and edit them in-place. If you're Web Control Pages and you keep your PRG files with the script page file, the two files live side by side and you can edit them.

It's also useful for checking out generated script template PRG files while debugging code and you can also open Process class files (manually) in the editor and see your process class code side by side with a template.

Keep in mind the features are limited to syntax coloring. There's no auto-complete support, so you may still want to use the Web Connection add-in to explicitly open FoxPro files in the FoxPro editor.

Other Editors with Web Connection?

FWIW, you don't have to use Visual Studio or FoxPro either. If you want a different editor for your PRG files - like Sublime text as I've done for years - you can use the Open With... option to specify a default editor to open files with. You can map PRG files there to whatever editor you like including the VFP IDE.

Once done double clicking opens the file in the specified editor. I've been using Sublime for years because it fires up quickly, but now I may stick with the built in editor simply for the fact that everything is one place.

Web Connection and Editing FoxPro Files

Note Web Connection also supports opening Code behind files using the Web Connection Visual Studio Addin:

Web Control Pages automatically open the code behind file. For script and template pages a special page directive allows you to specify what file should be opened - notice the highlight in the code file above:

<% * SourceFile="~/../../fox/samples/wwdemo/wwdemo.prg" %>

which lets you specify what file is opened. Here it points at the Web Connection wwProcess class handler file as a relative path to the current document.

The editor that's used can be configured in web.config using the following settings:

        <add key="FoxProEditor" value="" />
        <add key="FoxProEditorAlternate" value="C:\Program Files\Sublime Text 3\sublime_text.exe" />

An empty string value means that the VFP IDE is used, otherwise the file specified by the path is used with the filename passed as parameter.

Any way you slice it - there are now quite a few options for opening FoxPro code in a decent editor - you get to choose what works best for you.

Custom Row and Column Rendering in Web Connection with HtmlDataGrid()

No comments
Thursday, June 30, 2016, 1:13:33 AM

DataGrids are popular use case for FoxPro developers who are obsessed with use data grids for data display. Personally I'm not a huge fan of grids, unless absolutely necessary, but for some use cases grids using HTML tables are the only way to go to display a lot of data on a form.

In this post I'll describe using the wwHtmlHelper HtmlDataGrid() function which makes it super easy to create grids, and specifically demonstrate how you can create customized displays for rows or columns to highlight content.

HtmlDataGrid() basics

HTMLDataGrid() is a wwHtmlHelper function that is used to render data from tables or collections/arrays into an HTML table. It uses the new Web Connection 6.0 Bootstrap styling to create attractive grid displays fairly easily.

The function supports a couple of different operational modes:

  • Auto-Column generation from a cursor
  • Custom Column Definitions

Auto Column Generation

The former is super easy - it simply takes a cursor and renders it.

SELECT albums.pk,albums.title, albums.year, ;
       artists.pk as artistpk, artists.artistName  ;
    FROM albums, artists ;
    ORDER BY albums.title ;
	WHERE albums.ArtistPk = artists.Pk AND ;
	      artists.ArtistName = ?lcFilter ;	

* ... other header rendering

*** Render the Grid
Response.Write( HtmlDataGrid("TQuery") )

* ... other page rendering

Alternately you can also capture the HTML in your controller code:

pcHtml = HtmlDataGrid("TQuery") 

and you can then render the HTML inside of a template or script page:

<div class="gridcontainer">
    <%= pcHtml %>

In either case, this produces a simple table list of all the records:

If you want a little more control you can add a HtmlDataGridConfig object to configure a few options like paging and styling of the table:

loConfig = CREATEOBJECT("HtmlDataGridConfig")
loConfig.PageSize = 10             && 10 items per page
loConfig.PagerButtonCount = 5      && Max page number buttons in pager

Response.Write( HtmlDataGrid("TQuery",loConfig) )

which turns the grid into a paged grid:

Auto-column generation is very easy but it's fairly limited. As you can see you can't easily control what fields are displayed (the pks are showing) unless you modify your query to return only the fields you want, and the titles are determined by the field names.

It works for quick and dirty stuff, but in most cases you'll want to use custom grid columns.

Custom Column Definitions

The better approach is to explicitly define your columns for the data grid which gives you a lot more control. When using columns you can add custom styling, apply formatting and even use code expressions to transform the content. For example, it's fairly easy to call other helpers for adding things like links or checkboxes, or use entire custom functions for rendering the content of individual columns.

The following example demonstrates a few custom features:

SELECT albums.pk,albums.title, albums.year, ;
       artists.pk as artistpk, artists.artistName ;
    FROM albums, artists ;
    ORDER BY albums.title ;
	WHERE albums.ArtistPk = artists.Pk AND ;
	      artists.ArtistName = ?lcFilter ;	

* ... other HTML generation
*** Use the HtmlDataGrid Helper function (easier)
loConfig = CREATEOBJECT("HtmlDataGridConfig")

*** Paging is a problem when you dynamically switch between the two modes
*** so leave out for now
loConfig.PageSize = 6

*** Add a column explicitly by craeating it first
*** Note this column uses an expression that is evaluated for each record
loColumn = loConfig.AddColumn([HtmlLink("ShowAlbum.wwd?id=" + TRANSFORM(Tquery.pk),Title)],"Album")
loColumn.Sortable = .T.
loColumn.SortExpression ="Upper(Title)"

loColumn = loConfig.AddColumn("ArtistName","Artist Name")
loColumn.Sortable = .T.
loColumn.SortExpression ="Upper(ArtistName)"
loConfig.AddColumn("Year","Year Released","N")

*** Add a checkbox column
loConfig.AddColumn("HtmlCheckBox([chkIsActive_] + TRANSFORM(Pk) ,[],Year > 2000)","Recently Produced")

lcHtml = HtmlDataGrid("Tquery",loConfig)


which looks like this:

Notice that we have a link and a checkbox embedded into this display - using additional HTML helpers to render these items. You can embed any string expressions - including other HTML helpers which makes it easy to create more complex items in cells.

Additionally you can also create column output from expressions which can be either native FoxPro functions (for formatting for example), User Defined Functions, or class method calls.

To do this simply create the column expression with the function name:

loColumn = loConfig.AddColumn([Process.LinkAlbum()],"Album")

You can then implement this function on the Process class. Note it doesn't have to be a Process class method it just has to be something that's in scope called further down the call stack.

Customizing Column Display

In this function you can do whatever you want to do. So if you want to create a custom column that bolds the link you could do:

FUNCTION LinkAlbum()
LOCAL lcHtml
lcHtml = [<a href="ShowAlbum.wwd?id=] + TRANSFORM(TQuery.pk) + [" ]  +;
		 [  style="font-weight: bold; color: green;">] +;
         EncodeHtml(TQuery.Title) + [</a>]


Which now renders a bold green texted link.

Not very practical, but you get the idea - you can pretty much generate any HTML using a function that creates the HTML string output. It's very powerful.

Customizing the Column Styling

You can also access the Column's own styling and attributes using the ActiveColumnAttributeString property for the config object. For example to turn the Year column to a green background when the year is newer than 2000 you can use code like this:

loConfig.AddColumn("Process.YearColumn(loConfig)","Year Released","N")

Then create the handler:

FUNCTION YearColumn(loConfig)

IF (TQuery.Year > 2000)
   loConfig.ActiveColumnAttributeString = [ style="background: green; color: white" ]
   loConfig.ActiveColumnAttributeString = [  ]

The ActiveColumnAttributeString allows you to customize the <td> element with custom attributes which gives you full control over rendering.

Here's what the green boxed cell looks like:

Customizing Row Rendering

Finally it's also possible to affect row rendering using the OnBeforeRowRender() and OnAfterRowRender() handlers. These handlers also take expressions that have to return a string. Using these functions it's possible to get access to the row header and the individual column headers.

This is similar to the column customization except you use the RowAttributeString to customize the row.

First hook up the OnBeforeRowRender handler with the function expression:

loConfig.OnBeforeRowRender = "Process.RenderRowHeader(loConfig)"

Then implement the method:

FUNCTION RenderRowHeader(loConfig)

IF (TQuery.Year > 2000 )
	loConfig.RowAttributeString = [ class="highlight" ]
    loConfig.RowAttributeString = []

In this example, rather than setting an explicit style I simply assign a custom CSS class defined in a style sheet:

.highlight {
    background: #c6f1c6 !important;

which applies a light green background to the entire row. The !important forces the background to override other styles.

When you now render this grid you get:

Note that you have to always set the RowAttributeString to a value including the empty value, because when you set it that value stays for all subsequent requests. So effectively you have to reset it for each row.


As you can see you have a lot of control when rendering HtmlDataGrids with columns and values, even if the mechanism by which this works is not very obvious. But with a proper reference like this blog post it's easy to pick the right choice to customize your column or row render to match your needs exactly with very little code effort.

Calling JSON REST Services with FoxPro and wwJsonServiceClient

Thursday, May 26, 2016, 11:54:21 PM

A few days ago I released version 6.0 of the West Wind Client Tools which includes a little gem of a class called wwJsonServiceClient that makes it super easy to call JSON REST services. This class is part of the West Wind Client Tools as well as West Wind Web Connection and it makes it a snap to call JSON services to receive and send data.

Calling REST Services

REST services are becoming more and more popular and are starting to crowd out SOAP based services as the vehicle to share raw data over the Internet. Where SOAP is a very heavy XML based protocol that requires a very strict format, REST generally uses much simpler structures to push data over the wire. Data is usually encoded as JSON rather than XML. JSON is essentially a way to express JavaScript values, objects and arrays as a literal string value, which is easy to create and parse using standard libraries. Like XML, JSON is a serialization format, but unlike XML it skips all the formality and provides just the data.

If you're retrieving data from online social services or 'new Web' companies, you're going to encounter REST and JSON APIs generally. The benefit of REST JSON services is that generally they are much simpler than SOAP counterparts as you don't have worry about XML data mapping descreprancies. You don't need any special software to access a REST service - there's no SOAP client that has to parse a SOAP message and call. You simply have a documented endpoint and a set structure of data to send in (if any) and a set structure of data that is returned. All you need to access a REST service is an HTTP client (like wwHttp) and if the data is in JSON format a JSON serializer (like wwJsonSerializer).

On the server side things are also easier because again there's not additional contract that needs to be created. To create a REST service you build plain HTTP endpoints and return a JSON value or object. If you're using FoxPro in Web Connection the wwRestProcess class makes it easy to create FoxPro based REST services by simply creating classes that take a single input parameter and return a single result value. The wwRestProcess class handles all the logistics of publishing that data.

What is wwJsonServiceClient?

You can think of wwJsonServiceClient as a simple way to call a REST service. At it's simplest it's a high level wrapper class that wraps the wwHttp and wwJsonSerializer to call JSON services via HTTP and handles the JSON serialization and deserialization.

In a nutshell it reduces calling a REST service to a single line of code.

Making a GET Request

Let's try it out. The following calls a sample site to retrieve a list of Music Albums from an online AlbumViewer sample I created for last year's Web Connection Training.

This first request is a simple GET command that retrieves the list of albums like so:

do wwhttp
do wwJsonSerializer

loProxy = CREATEOBJECT("wwJsonServiceClient")

*** Make the service call
loAlbums = loProxy.CallService("http://albumviewerswf.west-wind.com/api/albums",
? loProxy.cErrorMsg

lnCount = loAlbums.Count

* ? loAlbums.Item(1).Title

FOR EACH loAlbum in loAlbums 
   ? loAlbum.Title  + ;
     " by " + loAlbum.Artist.ArtistName + ;
     " (" +  TRANSFORM(loAlbum.Tracks.Count) + " tracks)"
   FOR EACH loTrack IN loAlbum.Tracks
		? "  " + loTrack.SongName

The key is this line:

loAlbums = loProxy.CallService("http://albumviewerswf.west-wind.com/api/albums","","GET")

which makes an HTTP GET request to the server with not data to send to the server (empty second parameter). The last two parameters are actually not required - if no data is passed GET is assumed for the HTTP verb. You've just simplified a service call to single line of code.

POSTing data to a server

Along the same lines you can also post data to a server by passing a value, object or array to the server as the second parameter and changing the HTTP verb.

loArtist = CREATEOBJECT("Empty")
ADDPROPERTY(loArtist,"Description","Old school German Metal band")

loProxy = CREATEOBJECT("wwJsonServiceClient")
loArtist = loProxy.CallService("http://albumviewerswf.west-wind.com/api/artist",loArtist,"PUT")

IF  loProxy.lError
   ? loProxy.cErrorMsg

? loArtist.Albums.Count

Now in this case the call fails because you actually have to log in first, but if you hook up an HTTP proxy like Fiddler you you'll see the following was sent to the server:

PUT http://albumviewerswf.west-wind.com/api/artist HTTP/1.1
Content-Type: application/json
User-Agent: West Wind Internet Protocols 6
Host: albumviewerswf.west-wind.com
Content-Length: 194
Pragma: no-cache
Cookie: _ga=GA1.2.1516538738.1449808058; albv=C03E01F1F67F15336

 "description":"Old school German Metal band",

So you can see that the service client is generating an HTTP request with a JSON payload from your method call.

Dealing with FoxPro Case Limitations

Now it turns out that the service actually expects all the property names to be proper case. FoxPro's property retrieval API unfortunately does not natively support preserving case (except if you use MemberData which is a pain in the ass) and so the serializer by default turns all property names into lower case.

If you need to communicate with a service that requires either proper or camel case (which is common for JSON services) you can override property names explicitly.

loProxy = CREATEOBJECT("wwJsonServiceClient")

*** Create a custom serializer that overrides property names
loSer = CREATEOBJECT("wwJsonSerializer")
loSer.PropertyNameOverrides = "Id,ArtistName,Description,ImageUrl,AmazonUrl"

loArtist = loProxy.CallService("http://albumviewerswf.west-wind.com/api/artist",loArtist,"PUT")

IF  loProxy.lError
   ? loProxy.cErrorMsg

? loArtist.Albums.Count

Now the data is sent with proper names:

 "Description":"Old school German Metal band",

These overrides are applied globally to all properties, child properties and array items so this addresses the FoxPro type name limitations.

HTTP Verbs

The above example used a PUT command to update an existing record. POST is typically used to add a new record, there's also DELETE and HEAD and a few other verbs. The verbs are usually determined by the service interface which should be provided by the documentation for the service.

Verbs can be used to differentiate operations on the same URL. For example, in the Item Service above I can use the Artist endpoint with GET and an ID to retrieve an artist. With POST a new artist is added, PUT updates an artist and DELETE removes an artist all from the same http://albumviewerswf.west-wind.com/api/artist Url. This is a common pattern and this approach lets you work with that.

Make it Better

Ok, so the above works, but you really don't want to scatter code like this into your application logic. It's a much better idea to abstract the service implementation into its own class with methods for each of the operations you want to perform.

Instead I recommend that when you access a service, you create a class that inherits from wwJsonServiceClient and then implement methods that make the service call. This can simply error handling and puts all the code related to the service - including any possible pre and post processing you might do for each call - into a single class.

So if we refactor our two service functions we might end up with a class like this:

DEFINE CLASS AlbumViewerService as wwJsonServiceClient

*  Init


*** Ensure a serializer exists


*  GetAlbums
FUNCTION GetAlbums()
LOCAL loAlbums

loAlbums = THIS.CallService("http://albumviewerswf.west-wind.com/api/albums","","GET")

*** Error message is already set
IF THIS.lError
   RETURN null

RETURN loAlbums

*  UpdateArtist
FUNCTION UpdateArtist(loArtist)
LOCAL loArtist

this.oSerializer.PropertyNameOverrides = "Id,ArtistName,Description,ImageUrl,AmazonUrl"

loArtist = THIS.CallService("http://albumviewerswf.west-wind.com/api/artist",loArtist,"PUT")

*** Reset overridden properties
this.oSerializer.PropertyNameOverrides = ""

IF THIS.lError
   RETURN null

RETURN loArtist


By doing this you're abstracting all the logic required to deal with the service in this class, so the application doesn't need to see this low level interaction.

To use the service and call both methods the front end code you might use inside of your application looks like this:

*** Create our CUSTOM service
loProxy = CREATEOBJECT("AlbumViewerService")

*** call the wrapper method
loAlbums = loProxy.GetAlbums()

lnCount = loAlbums.Count
* Do something with the data

loArtist = CREATEOBJECT("Empty")
ADDPROPERTY(loArtist,"Description","Old school German Metal band")

loAlbum = loProxy.UpdateArtist(loArtist)
IF  loProxy.lError
   ? loProxy.cErrorMsg

? loArtist.Albums.Count


This is much cleaner as you are calling simple methods that describe what's happening. If something goes wrong, you have one place to go to look for the failures and the service becomes now reusable.


REST services are becoming much more common and although they are easy to call if you have an HTTP client and JSON serializer, wwJsonSerializer offers a more simpler, more abstracted and consistent way of doing it for you. Errors are caught and passed back to you and it reduces the service call to essentially a single line of code potentially with some extra configuration if you need to post data to the server that requires proper casing.

Give wwJsonSerializer a try. It's available in West Wind Client Tools 6.0 and West Wind Web Connection, but the Web Connection version is not quite up to date and is missing the CreateSerializer() method. This will be addressed in the forthcoming v6.05 release due out shortly.

Web Connection 6.0 RTM is here

No comments
Monday, April 4, 2016, 12:00:00 AM

It's been a long journey but I'm happy to announce that Web Connection 6.0 RTM is finally here.

To be honest it's taken a lot longer than I anticipated to do all the things I had set out to do with this release. The main brunt was to clean up the rough edges of the framework and the tooling and to make it much easier to build, deploy, update and manage Web Connection applications, which traditionally has been one of its weak points. Because there are lots of externalities in this process, it took a long time to fine tune and test and re-rest to make sure that these processes are streamlined as much as possible.

Functionally, most of the features I set out to provide were complete at the Southwest Fox conference last October, but all the plumbing around the UI updates and documentation updates and some of the infrastructure features ended up taking a long time to get just right and baked, and then run through some extensive testing in a few live applications. So here we are 5 months later…

But now that time is past and Web Connection 6.0 RTM is now available:

Web Connection 6.0 is a paid upgrade from previous versions unless you purchased Web Connection 5.x after April 1st, 2015 in which case you get to upgrade for free. If you previously purchased an upgrade to the full version of Web Connection 6.0, you should have received an update download notice via email – if not contact me privately. If you own any previous version of Web Connection (yes – all the way back to v1 in 1995!) you can take advantage of upgrading to the latest version of Web Connection. And if you hurry and purchase an upgrade before the end of the week you can still save 10% from the Beta discount that we offered during the pre-release cycle.

What's New?

Web Connection 6.0 is a major update to Web Connection. There are many, many new features and enhancements in this release. But at the same time, the new version has very little impact on backwards compatibility. There are very few, and very minor breaking changes between v5 and v6, so existing 5.x application will run under 6.0 with just about no changes which you can find in a section on breaking changes (look for the yellow box at the end of the change list) of the What's new topic in the documentation.

If you check out the What's New list in the documentation, you'll find that Web Connection 6.0 has a lot of new features and enhancements. There are a handful of big features like the new project system, the administration features and the new Scripting enhancements that I'll cover below. The rest are mostly API enhancements or extensions that are small enhancement to address very specific needs.

New Project System

Probably the most noticeable new feature is the new project system in 6.0. In the past Web Connection didn't really have the concept of 'project' as you simply worked out of the Web Connection folder or you come up with your own strategy for isolating your application specific code. While you could always structure your projects any way you wanted, Web Connection itself never imposed any structure to a project. It still doesn't force you into a particular structure but newly created projects now create a very specific and repeatable folder structure that builds a self-contained and portable structure that I call a 'project' (which is simply files and folders).

In the past I've always shied away from making this particular change, because managing paths in a development environment is difficult and because Web Connection apps depend on finding the the Web Connection code there were always issues. In this release I've overcome my reservations about this and addressed the pathing issues with generated configuration and startup files that can ensure proper dependency discovery. If you leave things in default locations things will just work – otherwise making a path change in config.fpw or setpaths.prg will get you on your way.

So in Web Connection 6.0 there's the concept of a project layout, where a new project is created into a self-contained folder structure. The project gets a top level folder, and subfolders for \web, \deploy and optionally \data. A related feature allows use of relative paths in the server configuration files so that you can basically set up your dependencies entirely based on relative paths. Because projects have a known structure the New Project and New Process Wizards can make assumptions where related files live and automatically and without user interaction create a fully portable application layout.


By default new projects are created under a WebConnectionProjects folder, but that's not really important. Each project has its own self contained folder hierarchy that includes both the source code (Deploy) and Web directories (Web). Upon configuration the Web folder is configured as a Web virtual folder or root site, in place right in this folder.

There are few huge benefits to this:

  • Portable Application Structure
    This means you can copy your project to a new location and simply recreate/configure the virtual in the new folder and the application should simply work. This also means that you can take an project folder and push it to the server and with very minimal configuration make it work.
  • Easier Configurability
    Because the default project structure is known, the configuration Wizards can be much simpler and not ask a bunch of previously confusing (to new users) questions. For example for a new project you now specify the path to the main project folder and any script maps you want to create and that's it. No more pointing at DLLs, temp folder location or web paths – files just get copied and associations created.
  • Automated Configuration
    Because of the known dependency locations, it's now possible to auto-generate a configuration script that can completely auto-configure a typical Web Connection project. When you create a new project now Web Connection creates a PRG based script file that automatically compiles into your server EXE that creates the virtual directory, Application Pool, Scriptmap(s) and sets folder permissions for your project. When you deploy your application to a live server you can now do MyApp.exe CONFIG and this automated script will automagically configure your application. The script can be customizes as it's just a PRG file and based on the project relative default settings. You can customize this script if you want to use non-default paths, or add to it and handle application specific install features (creating data folders, mapping drives, copying data etc.).

To me personally this has been a big win. Over the weekend I moved over my Web Connection servers to Version 6.0 and in the process I moved the folder structures of several applications to the this model. I was able to take a generated configuration script and modify 3 lines of code to make it work against my new setup. I was able to let the script configure my Web and security setup in minutes rather than the typical 15-30 minutes.

Automatic Configuration Scripts

When you create a new Web Connection application, an automated Web server configuration script is generated as part of the creation process. The script creates configures IIS, creates scriptmaps, sets application paths and folder permissions. The script is generated as a PRG file called MyApp_ServerConfig.prg which also gets added to your project and can be invoked when you run the main application with a CONFIG parameter. Because it's a PRG file you can look at it, modify it and add functionality to it if you want.

The script is compiled into your server, so from a command prompt you can do:

MyApp.exe CONFIG

and that configuration script is fired.

The script can be configured interactively via MyApp.ini and the [ServerConfig] which allows you to specify the IIS instance to configure on, the virtual directory and scriptmaps to create:


The IIS path is the IIS Web site instance which above is 1 or the default instance. If you configure another site, you can look up the instance ID and replace it.

The configuration script is just FoxPro code, that you can look at and if you choose modify. The default implementation uses the default project structure to assume where things need to go.

A typical configuration script looks like this:

*  Testproject_ServerConfig
***  Function: Templated Installation routine that can configure the
***            Web Server for you from this file.
***            You can modify this script to fit your exact needs
***    Assume: Called from TestprojectMain.prg startup code
***            with CONFGI parameter
***            Launch with from the Windows Command Line
***            Testproject.exe config
***            or with a specific IIS site/virtual
***            Testproject.exe config "IIS://localhost/w3svc/2/root"
***      Pass: lcIISPath  -  IIS Configuration Path (optional)
***                          IIS://localhost/w3svc/1/root
DO wwUtils    
IF !IsAdmin() 
   MESSAGEBOX("Admin privileges are required to configure the Web Server." + CHR(13) +;
              "Please make sure you run this exe using 'Run As Administrator'",;
              48,"Testproject Server Configuration")
*** Try to read from Testproject.ini [ServerConfig] section
lcIniPath = FULLPATH("Testproject.ini")
lcVirtual = loApi.GetProfileString(lcIniPath,"ServerConfig","Virtual")
IF ISNULL(lcVirtual)
  lcVirtual = "TestProject"
lcScriptMaps = loApi.GetProfileString(lcIniPath,"ServerConfig","ScriptMaps")
  lcScriptMaps = "wc,wcs,wcsx,tp1"  
  lcIISPath = loApi.GetProfileString(lcIniPath,"ServerConfig","IISPath")
     *** Typically this is the root site path
    lcIISPath = "IIS://localhost/w3svc/1/root"
*** Other relative configurable settings
lcVirtualPath = LOWER(FULLPATH("..\Web"))
lcScriptPath = lcVirtualPath + "\bin\wc.dll"
lcTempPath = LOWER(FULLPATH(".\temp"))
lcApplicationPool = "WebConnection"
lcServerMode = "IIS7HANDLER"     && "IIS7" (ISAPI) / IISEXPRESS
loWebServer = CREATEOBJECT("wwWebServer")
loWebServer.cServerType = UPPER(lcServerMode)
loWebServer.cApplicationPool = lcApplicationPool
   loWebServer.cIISVirtualPath = lcIISPath
WAIT WINDOW NOWAIT "Creating virtual directory " + lcVirtual + "..."
*** Create the virtual directory
IF !loWebServer.CreateVirtual(lcVirtual,lcVirtualPath)   
   WAIT WINDOW TIMEOUT 5 "Couldn't create virtual."
*** Create the Script Maps
lnMaps = ALINES(laMaps,lcScriptMaps,1 + 4,",")
FOR lnx=1 TO lnMaps
    lcMap = laMaps[lnX]
    WAIT WINDOW NOWAIT "Creating Scriptmap " + lcMap + "..."
      llResult = loWebServer.CreateScriptMap(lcMap, lcScriptPath)        
    IF !llResult
       WAIT WINDOW TIMEOUT 2 "Failed to create scriptmap " + lcMap
WAIT WINDOW NOWAIT "Setting folder permissions..."
lcAnonymousUserName = ""
loVirtual = GETOBJECT(lcIISPath)
lcAnonymousUserName = loVirtual.AnonymousUserName
loVirtual = .NULL.
*** Set access on the Web directory -  should match Application Pool identity
* SetAcl(lcVirtualPath,"OtherUser","F",.T.,"username","password")
*** IUSR Anonymous Access
IF !EMPTY(lcAnonymousUserName)
    llResult = SetAcl(lcVirtualPath,lcAnonymousUserName,"R",.T.)
    *** No unauthorized access to admin folder
    lcAdminPath = ADDBS(lcVirtualPath) + "Admin"
    IF DIRECTORY(lcAdminPath)
          llResult = SetAcl(lcAdminPath,lcAnonymousUserName,"N",.t.)
*** Set access on the Temp directory - should match Application Pool Identity
SetAcl(lcTempPath,"NETWORK SERVICE","F",.T.)
* SetAcl(lcTempPath,"OtherUser","F",.T.,"username","password")
*** COM Server Registration
IF FILE("Testproject.exe")
   RUN /n4 "Testproject.exe" /regserver
   *** Optionally set DCOM permission - only set if needed
   *** requires that DComLaunchPermissions.exe is available
   * DCOMLaunchPermissions("Testproject.TestprojectServer","INTERACTIVE")
   * DCOMLaunchPermissions("Testproject.TestprojectServer","username","password")
WAIT WINDOW Nowait "Configuration completed..."

As you can see Web Connection includes all the features needed to configure servers via code and the default generated PRG file just uses these features and applies it to the default project structure using the relative paths to figure out where things need to be configured.

The bottom line is this: You can move your project to a new location and run this script and your application will simply run. Likewise you can deploy an application to the server and assuming the Web Server is installed and has the base configuration required, you can run MyApp.exe CONFIG and your application is configured and ready to go.

This is a big change from previous versions were you either had to manually configure or else run the confusing Configuration Wizard. Best of all you can review the script above and get a good idea what configuration settings are made to get your application to run and you can modify the script to make changes or add additional configuration options.

Seeing this work for the first is almost magical – the script just runs for a few seconds and once done you can start your server, browser your site and you're off to the races.

Deploying Applications

Web Connection 6.0 can also help you deploy applications. Configuration is one thing but if you need to deploy and update applications you still have to get your files to the server.


First a new Web Connection project includes a build.bat file that creates a \build folder that contains all the project dependencies that a Web Connection application typically needs to deploy. The script picks up all dependent binary DLLs, the main binary file (your exe) and configuration file (.ini) and dumps those files into a the \build folder and zips everything up (if 7zip is in your path).

Here's what the build folder looks like:


You can then push that file to the server and unpack it there for installation. You might have to add additional files for your installation, but this is a quick way to get all the dependencies that Web Connection typically needs in one quick swoop.

File Upload

The Web Connection .NET Handler includes a new feature to upload files into the application's \temp path on the server. Which is a poor man's way of copying files to the server if RDP file transfer is too slow (as it usually is) or you don't have an FTP server running on your site:


Just make sure you set the appropriate request limits in web.config to allow your Web server to accept large file uploads – temporarily if necessary (you can bump it back down after you're done uploading).

This is very useful if you need to upload say the Visual FoxPro runtimes, or your application or application data.

Updating Applications

Web Connection has always included tools to allow you to hotswap running applications by uploading new binary files and swapping them while the application is running. In the screen shot above the Upload Server Exe and Update Server Exe links accomplish this using the ExeFile and UpdateExeFile configuration keys. The way this works is that you can upload a new binary with the Upload link, which uploads the file to the file name specfied in UpdateExeFile. The Update Server link then shuts down all running servers and copies the new EXE file and restarts all servers.

This functionality is not new but it has been streamlined in Web Connection 6.0. The feature now works both with COM and file based Messaging. Additionally the hotswapping routine now gives you detailed info on the uploaded file including file size and version number so you can validate that the file made it and got swapped out. The upload process is now integrated into the Web Connection .NET Handler so you don't have to have a Web Connection server running in order to upload the file. This means you can use this feature to push an initial EXE to the server.

Finally new projects generate a bld_MyApp.prg file that automates this process. This bld file can be used to compile your project and show errors but if you do:

DO BLD_MyApp with .T.

The script will try to upload your binary file to your server. For this to work you have set a couple of values in the PRG file to point at the server where your application will be updated.

This is a great way to update the binaries in your application in a few minutes, causing a mere few seconds of downtime on your server only as your servers are hotswapped. I use this feature all the time to update my code online and it takes all but a minute to get new bianaries uploaded and hotswapped on my live server.

All of the features I've highlighted so far are administrative features meant to make it easier to manage Web Connection applications. For my own workflows I can tell you that these simple improvements have made the process of managing a Web Connection application considerably easier and more predictable. I hope you find these lifecycle features as useful as I have.

Modern Styling and Mobile Friendly Layout

Web Connection's existing base styling in Web Connection 5.0 was getting a bit - quaint. Initially created in the early 2000's the styling is showing it's date – it's looking decidedly old school. Not only that but the existing styling was completely custom, designed by a non-UI person (me) as best I could. The CSS and base markup was pretty stable, but by now the style is definitely very dated looking.

Web Connection 6.0 takes a different approach by relying – by default – on a popular, external CSS libraries designed by real designers and used widely by many developers for building Web applications.  Web Connection 6.0 uses Bootstrap with a somewhat customized base theme and FontAwesome for its default theming to provide a more consistent and much more popular design.

Web Connection uses these base libraries and then layers a relatively small customized UI on top of it. So when you create new pages in Visual Studio or use the default script templates, you get this base customized Bootstrap UI.

To be clear, this is just a default to get you started with. As before you can still build completely custom CSS and use it with your Web Connection applications, but if you are not graphically inclined you can build reasonably nice looking and mobile friendly applications relatively easily. Although Web Connection provides a slightly customized Bootstrap layout, all the default Bootstrap styles and components are available to you to use so it's possible to completely override our custom styling with your own.

Web Connection's customization essentially throws out Bootstraps default nav header,  which doesn't work very well on mobile and provides a slide in side menu via the bars on the left in the screen shot below:


The default styling is mobile friendly as long as you stick to the general bootstrap design guidelines (using content containers and the grid layout). Here's the same form displayed on my iPhone 6. The first picture is plain the second with the animated slide in menu opened.


(this Web Connection sample is available on BitBucket if you want to check out a more comprehensive Web Connection sample app).

Visual Studio Page Templates

This sample, uses mostly the default styling that comes out of the box with Web Connection. If you are using Visual Studio, there a number of templates you can use to create various types of pages that include this default styling:


Use of Visual Studio is completely optional – you can use any editor you chose, but you do get a few benefits in Visual Studio. One are the templates above which make it really easy to create new pages that have all the standard styling and base page layout applied.

There's also a Web Connection Visual Studio Add-in that allows you to preview script and template pages  in your browser and that optionally allows you to show FoxPro code (if you have SourceFile="<file>" tag in your source file)

If you want to use other editors you totally can – I personally use Sublime Text with Matt Slay's Sublime FoxPro extension quite frequently, but any HTML editor like WebStorm, Atom, VS Code, Notepad++ will work as well. You won't get automatic templates, but if you want to cut and paste you can find the Visual Studio templates in the \VisualStudio\PageTemplates folder. If you drill into the various template folders you can find the default.* pages that contain the template and you can cut and paste from there.

As a side note you can also create your own Visual Studio templates – simply create a new zip file and use one of the other templates as a base and simply rename the manifest and final file names to create your own custom templates you can load in Visual Studio. Along the same lines if you're ambitious you can also create custom templates for Sublime, Atom or VS Code in much the same way.

MVC Style Development Improvements

Web Connection has long supported MVC style development using code based logic that can drive scripts or templates. This was one of the big features in Web Connection 2.0 in 1998. Nowadays MVC style frameworks like ASP.NET MVC, Ruby on Rails or Express on Node are the norm for server side Web development. In version 6.0 Web Connection gets a major updates for the Script and Template engines which now support master Layout pages that let you create a top level page template into which other content pages load, partial pages, which allow you to break large and complex pages into smaller pages and sections, which allow you to inject content from content pages into the master pages. These concepts are common in other MVC frameworks and they make it much easier to build complex applications as you don't have to repeat the same markup code on each page. Instead layout pages can take the brunt of page 'chrome' with various content areas that are filled by the content pages.

For those of you not familiar with scripts and templates in Web Connection, scripts and templates allow you to mix HTML markup and FoxPro code. The following demonstrates using a FoxPro SCAN to run through a cursor created by a controller method in the application's Process class:


MVC style development is the most popular mechanism of development with Web Connection from what I've observed what people are using and so this is why there has been renewed focus on this development style.

JSON Service Improvements

Web Connection 6.0 now has a dedicated RestProcess class that makes it super easy to create JSON REST services that can take JSON input and generate JSON output. To create JSON endpoints you simply add methods to the RestProcess subclass and the methods simply accept a single parameter (which can be a complex object) and returns back a result value. The input parameter is parsed from JSON to a FoxPro object and the result value, object, collection or cursor is turned into an JSON (or XML) document.

The New Project and New Process Wizards now give you options to explicitly create a standard Web application or a REST service.


wwJsonService now also includes .cPropertyNameOverrides which gets around FoxPro's limitation of reflecting property names only in lower case. Using a comma delimited list of property names you can override properties with proper case so you can create JSON objects that match a specific signature. wwJsonSerializer has been improved to handle collections better and has been updated to deal better deal with illegal FoxPro property names that are supported in JavaScript.

JSON Client Features

There's also a new wwJsonServiceClient class that makes it much easier to call JSON services. Using this class you can create methods for each service call and the methods can call a CallService base class helper method to actually call the Web based REST service method. You specify a URL and a single value or object parameter which is serialized and sent as JSON to the server. The JSON result that comes back is automatically parsed back into a FoxPro value or object. wwJsonSerializer now has a .FormattedOutput  flag to create pretty printed JSON output.

New wwHtmlHelpers

In Web Connection 5.50 Web Connection introduced a new library of HtmlHelpers that provide rich control functionality by way to of functions that can render certain controls and control values. These 'control' functions can be used with MVC style scripts or in code to generate HTML. The various input controls like textbox, textarea, checkbox, radio etc. all support databinding making it easier to bind data to these controls.

For example, here are the HtmlTextArea and HtmlBindingError helpers handling databinding for bound business object entity:


While  the code is a bit verbose this code provides two way databinding support – the control is smart enough to display values from the model on a GET operation and display the posted back values when a POST/PUT operation is active. Likewise the checkbox and radio helpers know how to deal with the undermined state issue you run into with this painful HTML controls that don't differentiate between unchecked and not set values.

There are a number of new Html Helpers:

  • HtmlBindingError
  • HtmlDataTextBox (bootstrap datepicker)
  • HtmlErrorDisplay (bootstrap alert box)

There are also a number of updates to the HtmlDataGrid component.

Markdown Support

Markdown has become massively popular as an easy data entry format for HTML that can be written without actually writing HTML markup. Basically the text format uses very simple technical editing style markup directives using plain characters to describe common markup operations. This markdown text can then be parsed down to HTML. For most free form text data entry operations using plain text like this is much more efficient than using a rich HTML editor. If you're new to Markdown check out my Markdown Basics document I publish in West Wind Html Help Builder.

Web Connection now includes a markdown parser that can turn Markdown into HTML very quickly, using a .NET Markdown component (CommonMark). A new Markdownparser class provides for parsing Markdown to html and there's also an easy Markdown() function that can be easily used in templates (assuming you've loaded Markdownparser.prg).

For scripts and templates you can also directly write markdown text into the document markup using <markdown>This is **Markdown Text**</markdown> syntax in templates and scripts which is automatically expanded.

Web Connection .NET Handler Updates

The Web Connection Handler also has a number of big updates. The most noticable is that the UI now uses an _AdminTemplate that allows for styling of the admin page. Rather than the bland generic page you now get a branded page like the rest of the application:

Likewise error and status messages use the same _AdminTemplate.html to display their content. You can customize this template with your own branding in your applications if you choose.

Hot Swapping of Live Servers for both COM and File Based

The .NET Handler now also internally handles hot-swapping of both COM and File Based servers (previously this worked only with COM). The handler can shut down all servers, put requests on hold and hot-swap server exes, then restart instances. The upload operation is now part of the .NET Handler, rather than the Web Connection server which means you can actually do first time uploads to the server of a new server and you're not dependent on a functioning EXE server to make the actual copy operation.

Updated Documentation

The Web Connection documentation has been overhauled significantly.  Web Connection's docs are very big but a lot of the general purpose and intro content has been updated for version 6.0. A lot of old stuff has either been cleaned up and updated, or thrown out when irrelevant.


New Walk through Tutorials

There are also several new walk through tutorials and I recommend if you're new that you go through these to understand how Web Connection works.

Fast and Mobile Friendly

The online documentation and Help file has been re-built with the latest version of West Wind Html Help Builder and provides a much more modern,  livelier, interactive browsing experience. Topics load much faster and the new search feature is nearly instant, simply filtering the topic list. The new design has responsive layout that is mobile friendly, and no longer uses ugly frames.

Quick Search

The search is feature is a key improvement and I really recommend you take advantage of it.

The topic search box is very fast in looking up topics, as is all client side and simply filters the list of topcis based on your search terms. This means you can type partial text and it will match. Typing IIS for example quickly shows you the IIS and IIS Express configuration topics as well as a few knowledge base topics. Typing Expand will bring up ExpandTemplate(), ExpandScript() and ExpandPage() topics you can then jump to directly. This sounds pretty ordinary, but the search is nearly instant which makes it very efficient to browse the documentation quickly and find what you need.

If you use Web Connection, create a browser shortcut to the help file now and use it whenever you need to look up any Web Connection related function or feature. I guarentee you, it'll make you more productive – I know it has done that for me!

New Message Board Sample

With all the new MVC and scripting features in Web Connection 6.0 I needed to build another full featured sample, and this version's target was the Message Board which has been completely re-written from the ground up using business objects and MVC style development using Process/Controller classes and Scripts. The result is a is a much cleaner implementation that is mobile friendly and much smoother and faster compared to the old frames based implementation. The new message board includes support for the popular Markdown text format for writing messages and includes a rich editor that makes it easy to create messages with attached images and nicely formatted code snippets.

If you haven't stopped by the message board recently, check it out to see all the changes and please join the conversation – I hope to make this place more active and get more people involved to keep this community alive.

The message board is a sample application that ships with all of its source code in the Web Connection package and you're free to run this message board on your own site.

I've also made the source code available on Github to allow people to get involved and get access to the latest versions and potentially add features or submit pull requests.

And so much more

There is much more of course, but here are a few more small tidbits:

There's now better support for extensionless urls, which are common for REST services that use 'noun' based URL endpoints (like customer, order etc). There are a number of new jQuery plugins: jQuery-resizable, jQuery-watcher, a generic debounce() function that lets you throttle event handling on a timed basis. The .NET Handler's COM loading has been drastically improved. COM servers should now load up twice as fast as before.

The Request object has many new functions that provide better access to file uploads with multiple files, collecting form variables into a collection,  Request.UnbindFormVars() lets you unbind form variables to an object and provides you a collection of validation errors (if any). Response.ExpandScript/ExpandTemplate() now default to the current script if no template path is provided. You can also use ~\ virtual paths to specify a web relative script name (ie. ~\admin\CustomerAdmin.wcs).

wwDotnetBridge has many, many improvements to allow accessing more and more features of the .NET type system from Visual FoxPro. There's now support for calling any .NET method asynchronously including the ability to be called back when the method completes.

If you're interested in everything new check the large What's New Topic link:

There are tons of small enhancements. New support functions, small improvements to others and a lot of updates.


It's been a long journey involving a lot of very tedious work, but it's been worth it even if these changes end up being mostly for my own use of Web Connection. The vast majority of the changes in this release address very specific usability scenarios that I think will be beneficial to just about anybody using Web Connection today and the new version is bound to make the development and especially the administration process much easier overall.

I know in my own work with several customers and also with the Web Connection sample app and the message board, it's noticeably easier to build and deploy applications with confidence. Because of the automated scripts the process of getting applications online and keep them updated is simply quicker and easier.

The new HTML Scripting features – Layout Pages in particular - make HTML development so much easier than previously because you can reuse so much of the standard page chrome without having to repeat yourself. This greatly reduces HTML you have to write. Couple that with the default templates (in Visual Studio) and it's extremely quick and productive to get new pages into the application.

I haven't been this excited about Web Connection in years and I wish I had spent the time to do this a few years back, but I simply did not have the time and resources to do it. In the last year I've finally set aside the time to make these necessary changes happen and you're looking at the end result of it.

And I'm not done yet either. There are a still handful of improvements that didn't make the cut for the RTM release, but that will be showing up in updates in the near future, so stay tuned for more cool stuff coming down the line.

I hope you find these updates as useful as I have. Enjoy.


Outlook Email Automation–Watch out for Administrator Access

No comments
Sunday, November 29, 2015, 10:38:36 PM

I was looking into creating prefilled emails using Outlook Automation earlier today and ran into an unexpected snag. The requirement was to display a pre-filled email that contains recipient, subject, body and one or more attachments and then display the prefilled email in Outlook.

This is fairly straightforward to do using COM Automation:

    *** NOTE: This fails if you run as Administrator (rather than the active user)
    loOutlook = GETOBJECT(,"Outlook.Application")
IF VARTYPE(loOutlook) != "O"
   loOutlook = CREATEOBJECT("Outlook.Application")
IF VARTYPE(loOutlook) != "O"
   MESSAGEBOX("Couldn't create Outlook instance")
loItem = loOutlook.CreateItem(0)
loItem.Body = "Hello World"
loItem.Subject = "New Test Message"
*** Add you files to attach here

Note that Outlook – as most Office Applications – is a Singleton object that expects to run only one instance. So if Outlook is already running you can use CREATEOBJECT() to create a new instance. Instead, you have to attach to an already running instance using GETOBJECT().

Gotcha: Running as Administrator makes GETOBJECT() fail

I typically run FoxPro as an Administrator because I frequently build COM objects, which requires that you run as a full administrator in order to write COM registration to the registry.

However, when running the above code, it turns out the GETOBJECT() call to capture Outlook.Application fails. It works fine when you run as a non-admin user or even as an Admin user when User Account Control (UAC) is enabled on the machine and your account is effectively running as a non Admin account.

But when you explicitly run as an Administrator either using Run As Administrator when you start the app, or from ShortCut properties, or if you have UAC disabled on the machine, you'll find that the GETOBJECT() call fails with:

OLE error code 0x800401e3: Operation unavailable.

The reason for this is that when you run as Administrator you are actually running a different user account (Administrator – duh) and that account can't actually access the running instance of Outlook that is already running on your desktop. The only workaround I could find is to ensure both Outlook and your application run in the same execution context. So it works if you run your app without administrative rights, or if you run your app as administrator as well as Outlook.

As you might expect it took me a long time to figure out WTF was going on here. According to all examples I've seen Outlook should be accessible with GETOBJECT(). It wasn't until I tried using wwDotnetBridge and COM Interop doing the same thing with .NET and getting the same response in FoxPro but not in LinqPad when I realized it must have something to do with the actual runtime environment. Sure enough – once I started VFP without Run as Administrator option, the code works.

String Tokenizing based on StrExtract()

Thursday, November 19, 2015, 6:18:43 PM

I've been building a number of solutions lately that relied heavily on parsing text. One thing that seems to come up repeatedly is the need to split strings but making sure that certain string tokens are excluded. For example, a recent MarkDown parser I've built for Help Builder needs to make sure it first excludes all code snippets, then performs standard parsing then puts the code snippets back for custom parsing.

Another scenario is when Help Builder imports .NET classes and it has to deal with generic parameters. Typically parameters are parsed via commas to separate them, but .NET generics may add commas as part of generic parameter lists.

Both of those scenarios require that code be parsed by first pulling out a token from a string and replacing it with a placeholder, then performing some other operation and then putting the the original value back.

For me this has become common enough that I decided I could really use a couple helpers for this. Here are two functions that help with this:

*  TokenizeString
***  Function: Tokenizes a string based on an extraction string and
***            returns the tokens as a collection. 
***    Assume: Pass the source string by reference to update it
***            with token delimiters.
***            Extraction is done with case insensitivity
***      Pass:  @lcSource   -  Source string - pass by reference
***             lcStart     -  Extract start string
***             lcEnd       -  Extract End String
***             lcDelimiter -  Delimiter embedded into string
***                            #@# (default) produces:
***                            #@#<sequence Number>#@#   
***    Return: Collection of tokens
FUNCTION TokenizeString(lcSource,lcStart,lcEnd,lcDelimiter)
LOCAL loTokens, lcExtract
IF EMPTY(lcDelimiter)
   lcDelimiter = "#@#"
loTokens = CREATEOBJECT("Collection")
lnX = 1
    lcExtract = STREXTRACT(lcSource,lcStart,lcEnd,1,1+4)
    IF EMPTY(lcExtract)
    lcSource = STRTRAN(lcSource,lcExtract,lcDelimiter + TRANSFORM(lnx) + lcDelimiter)
    lnx = lnx + 1 
RETURN loTokens
*   TokenizeString
*  DetokenizeString
***  Function: Detokenizes an individual value of the string
***    Assume:
***      Pass:  lcString    - Value that contains a token
***             loTokens    - Collection of tokens
***             lcDelimiter - Delimiter for token id
***    Return: detokenized string or original value if no token
FUNCTION DetokenizeString(lcString,loTokens,lcDelimiter)
LOCAL lnId, loTokens as Collection
IF EMPTY(lcDelimiter)
  lcDelimiter = "#@#"
    lnId = VAL(STREXTRACT(lcString,lcDelimiter,lcDelimiter))
    IF lnId < 1
    lcString = STRTRAN(lcString,lcDelimiter + TRANSFORM(lnId) + lcDelimiter,loTokens.Item(lnId))
RETURN lcString
*   DetokenizeString

TokenizeString() basically picks out anything between one or more start and end delimiter and returns a collection of these values (tokens). If you pass the source string in by reference the source is modified to embed token place holders into the the passed string replacing the extracted values.

You can then use DetokenizeString() to detokenize either individual string values or the entire tokenized string.

This allows you to basically work on the string without the tokenized values contained in it which can be useful if the tokenized text requires separate processing or interferes with the string processing of the original string.

An Example – .NET Generic Parameter Parsing

Here's an example of the comma delimited list of parameters I mentioned above. Assume I have a list of comma delimited parameters that needs to be parsed:

DO wwutils
lcParameters = "IEnumerable<Field,bool> List, Field field, List<Field,int> fieldList"
? "Original: " 
? lcParameters
*** Creates tokens in the lcSource String and returns a collection of the 
*** tokens.
loTokens = TokenizeString(@lcParameters,"<",">")
? lcParameters
* IEnumerable#@#1#@# List, Field field, List#@#2#@# fieldList
FOR lnX = 1 TO loTokens.Count
   ? loTokens[lnX]
? "Tokenized string: " + lcParameters
? "Parsed parameters:"
*** Now parse the parameters
lnCount = ALINES(laParms,lcParameters,",")
FOR lnX = 1 TO lnCount
   *** Detokenize indvidual parameters
   laParms[lnX] = DetokenizeString(laParms[lnX],loTokens)
   ? laParms[lnX]
? "Detokenized String (should be same as original):"
*** or you can detokenize the entire string at once
? DetokenizeString(lcParameters,loTokens)

IEnumerable<Field,bool> List, Field field, List<Field,int> fieldList

Notice that this list contains generic parameters embedded in the < > brackets so I can't just run ALINES() on this list. The following code strips out the generic parameters first, then parses the list then adds the token back in. The Tokenization allows picking out a subset of substrings and replace them with tokens so additional parsing can be done without the noise of the generic parameters in brackets that would otherwise break the parse logic. This is quite common in text parsing where you often deal with patterns that you are matching – and trying to avoid edge cases where the pattern breaks down. This is where I've found tokenization super useful.

Specialized Use Cases

In Help Builder I have tons of use cases where this applies as documents are rendered: In parsing code snippets out of documents for parsing because the code snippets are rendered 'raw' while the rest of the document gets rendered as encoded context. Links that require special fixup before being embedded into the document – the tokenization allows easy capture of the links, replacing the the captured token value and writing it back out with a new value. In Web Connection the various template parsers do something very similar with expressions and code blocks that get pulled out of the document then injected back in later as expanded values.

There are lots of variations of how you can use these tokens effectively.

This isn't the sort of thing you run into all the time, but for me it's been surprisingly frequent that I've had to do stuff like this and while this isn't terribly difficult to do manually, it's very verbose code that's ugly to write as part of an application. These two functions greatly simplify application code as it's shrunk to a couple of simple helper functions.

Maybe some of you will find this useful though…

Conference Materials from Southwest Fox

No comments
Tuesday, October 20, 2015, 6:33:07 PM

It's been a fun, but very busy week for me at Southwest Fox last week with 2 very long days of Web Connection training and then 3 more days of sessions at Southwest Fox.

There seemed to be a lot more excitement than in past years around alternate technologies and Web functionality than I have seen in recent years which I find refreshing. This seemed especially related to client centric, JavaScript based front end applications and in particular Angular Js for building your front end application code. There also continues to be a lot of pent up demand for building mobile friendly Web applications and even though I only briefly showed the hybrid Cordova application that seemed to get a lot of people very excited about the possibilities.

Anyway, if you were attending the conference or not, here are the links the for the materials for the main Southwest Fox sessions which are hosted in BitBucket repositories.

Building Mobile Web Applications with AngularJs, Bootstrap and Web Connection

This session demonstrated how to build a mobile friendly Web application that can scale from desktop down to a mobile phone and work well in all display sizes by way of a sample AlbumViewer application. This application showcases a number of mobile features such as mobile first design, rearranging user interface elements depending on device width and using a pure client centric JavaScript application to drive the front end with AngularJS. Angular JS provides the modularization, two-way databinding and a number of support features for driving the entire user interface from browser. A Web Connection wwRestService based backend rounds out this example to provide the service JSON data that the front end consumes, retrieving FoxPro objects and cursors and serving them as JSON responses. Finally there's also an example, of the same mobile Web application ported to Cordova (with very minimal changes) and running as a native application on iOS using the Visual Studio Tools for Apache Cordova Cordova.

Online Sample Application

Source Code for the AlbumViewer and related Code Samples

Slides and Session Notes

Creating and Consuming Web Services with Visual FoxPro and .NET

This session demonstrated how to build SOAP 1.x based Web Services, using .NET ASMX services as the intermediary to both create Web Services and also consume them using .NET. For the server side the samples demonstrate how to use OleDb for direct data access to FoxPro data, as well as using MTDLL COM objects for calling FoxPro business logic to return objects for consumption by .NET code. Both styles rely on some connecting .NET code to provide the service front end. For the client side the examples, demonstrate importing a Web Service from WSDL and generating a .NET class, then using wwDotnetBridge to call the generated .NET proxy.

Conference White Paper

Sample Projects and Slides on BitBucket

Web Connection Training TimeTrakker Server Side MVC Sample

During the two day training we focused on server side application development during the first day of the training. The example is a small time tracking application that is mobile friendly using Responsive Design and takes advantage of some of the new features in Web Connection 6.0 including Layout Pages, partials and sections.

Time Trakker Web Connection 6.0 Server Sample Application

West Wind Web Store Discount for SW Fox Attendees

I also want to remind those of you that attended SW Fox that there's a 10% discount available on all West Wind products. You can use the discount code SWFOX_2015 on the shopping cart to apply the 10% discount. Please provide your SW Fox badge number with your purchase to qualify.

Next Year's Southwest Fox

Dates for next year's Southwest Fox conference were announced for late September next year. If you haven't come before it's a great place to see people catch up with new ideas on how you can extend the life of FoxPro just a little longer while at the same time gaining new skills. Mark your calendar.

Web Connection 6.0 Feature: New Project Server Configuration Script

No comments
Friday, October 9, 2015, 11:50:25 AM

In Web Connection 6.0 there's an updated project Wizard that creates a new 'project' for you that is self contained. Web Connection 6.0 projects copy all files into a single folder hierarchy where both the Web folder and the Deploy (code) folder are under the same root. The result of this structure is that we can now more easily move projects around, and just as importantly configure various folder paths using relative paths that won't have to change when a project is moved.

All of this makes it much easier to deploy projects by simply copying the entire structure to a new deployment location.  The idea is to make it easier to configure a Web Connection application on the server by automating the server configuration with a few simple steps that you can perform before you deploy your application on the server.

A Server Configuration Script

When a new project is generated Web Connection creates among other files a YourApp_ServerConfig.prg file. This plain FoxPro code file contains a small bit of code that uses server configuration code provided with Web Connection to:

  • Create a Virtual Directory for your Application
  • Add to an Application Pool (Web Connection by default)
  • Add Basic and Windows Authentication
  • Create Script Maps for your Application
  • Set Windows Permissions for your Application

Because the new project layout uses a known folder structure,  Web Connection can use relative paths to find the Web folder, temp folder and script paths, so it's easy to pregenerate a configuration script. I chose to generate a separate PRG file rather than generate a pre-compiled EXE file simply because it makes it possible to add additional configuration tasks to this script. Rather than pre-compiling this allows you the option to build a custom build script that can perform much more sophisticated tasks (like create multiple virtuals or add additional users to the ACL list etc.).

A typical generated XXXXX_ServerConfig.prg file looks like this (generated for a project called WebTest2):

*  Webtest2_ServerConfig
***  Function: Templated Installation routine that can configure the
***            Web Server for you from this file.
***            You can modify this script to fit your exact needs
***    Assume: Build this into an EXE file OR
***            add as a command line option to your
***            main application EXE (MyApp.exe "Configure")
***      Pass: lcIISPath  -  IIS Configuration Path (optional)
***                          http://localhost/w3svc/1/root
DO wwUtils    
*** Configurable settings
lcVirtual = "WebTest2"
lcScriptMaps = "wc,wcsx,wt2"
lcVirtualPath = LOWER(FULLPATH("..\Web"))
lcScriptPath = lcVirtualPath + "\bin\wc.dll"
lcTempPath = LOWER(FULLPATH(".\temp"))
lcApplicationPool = "WebConnection"
lcServerMode = "IIS7HANDLER"     && "IIS7" (ISAPI)
   *** Typically this is the root site path
   lcIISPath = "IIS://localhost/w3svc/1/root"
loWebServer = CREATEOBJECT("wwWebServer")
loWebServer.cServerType = UPPER(lcServerMode)
loWebServer.cApplicationPool = lcApplicationPool
   loWebServer.cIISVirtualPath = lcIISPath
WAIT WINDOW NOWAIT "Creating virtual directory " + lcVirtual + "..."
*** Create the virtual directory
IF !loWebServer.CreateVirtual(lcVirtual,lcVirtualPath)
*** Create the Script Maps
lnMaps = ALINES(laMaps,lcScriptMaps,1 + 4,",")
FOR lnx=1 TO lnMaps
    lcMap = laMaps[lnX]
    WAIT WINDOW NOWAIT "Creating Scriptmap " + lcMap + "..."
    llResult = loWebServer.CreateScriptMap(lcMap, lcScriptPath)        
WAIT WINDOW NOWAIT "Setting folder permissions..."
lcAnonymousUserName = ""
loVirtual = GETOBJECT(lcIISPath)
lcAnonymousUserName = loVirtual.AnonymousUserName
loVirtual = .f.
*** Set access on the Web directory
*** IUSR Anonymous Access
IF !EMPTY(lcAnonymousUserName)
   llResult = SetAcl(lcVirtualPath,lcAnonymousUserName,"R",.t.)
*** Set access on the Temp directory
SetAcl(lcTempPath,"NETWORK SERVICE","F",.T.)
WAIT WINDOW Nowait "Configuration completed..."

It's pretty easy to see what's going on in this file, right? The configuration section is just a set of values specified at the top. The code then generates the virtual and scriptmaps and sets permissions.

This is a generated PRG file that gets created in your project root. Because it's just a PRG you can modify it and add additional configuration steps to this file. You can add additional folders to configure, addition accounts to add to the security or even do other configuration tasks like copy files from a network location or download some related dependency into the deploy folder. It's entire open to you.

If you're using older projects you can still use this file and modify it to reflect your file locations explicitly in the configuration section.

Requires that IIS is installed and you have Admin Privileges

To be clear, this functionality configures IIS for your application, but you need to make sure that IIS is installed with the proper components first.

Note: IIS has to be installed and configured properly
The base IIS install has to be up and running on the machine and configured properly before this will work. You can find out more on how to configure IIS on recent versions of Windows.

Note: Admin Privileges requires
In order to configure IIS you have to be a full Administrator so you need to run a compiled EXE or the VFP IDE as an administrator in order for IIS configuration to work.

Running the Setup script

You can run this script from the FoxPro dev environment (make sure the Web Connection libraries are referenced):

DO WebTest2_SetupConfig.prg

remember if you do this inside of VFP's IDE make sure you started it as an Admin.

Embedded into your Server

The generated script however is also embedded into your Web Connection server via a command line parameter.  When you create a new project now your MAIN prg file is generated with a few parameters at the top and a little added code that calls out to the _SetupConfig file when a 'config' command argument is passed to the EXE:

*FUNCTION Webtest2Main
***   Created: 10/09/2015
***  Function: Web Connection Mainline program. Responsible for setting
***            up the Web Connection Server and get it ready to
***            receive requests in file messaging mode.
LPARAMETERS lcAction, lvParm1, lvParm2
*** This is the file based start up code that gets
*** the server form up and running
*** PUBLIC flag allows server to never quit
*** - unless EXIT button code is executed
   *** Load the Web Connection class libraries
       DO ("WCONNECT.APP")
          DO WCONNECT
   IF VARTYPE(lcAction) = "C" AND StartsWith(LOWER(lcAction),"config")
      do WebTest2_ServerConfig.prg with lvParm1
   *** Load the server - wc3DemoServer class below
   goWCServer = CREATE("Webtest2Server")
   IF !goWCServer.lDebugMode   
   IF TYPE("goWCServer")#"O"
      =MessageBox("Unable to load Web Connection Server",48,;
                  "Web Connection Error")
   *** Make the server live - Show puts the server online and in polling mode

When you now compile your Web Connection server into an EXE you'll have an option 'Config' command line switch that you can use to trigger the configuration process:

WebTest2.exe config

This will also trigger the configuration code to run.

There's a second commanline option you can apply providing an IIS meta base path (if you're configuring non-default Web site or virtual as a base):

WebTest2.exe config "IIS://localhost/w3svc/2/root"

which configures a different Web site (site with the ID of 2).

Running the utility should be very quick and only take a few seconds. You should see a couple WAIT WINDOWs flash by and then you're done.

If you want to double check whether things worked check:

  • Whether the virtual was created in IIS Manager
  • Whether the Script Maps were created in IIS Manager
  • Permissions in the Web and Temp folders

It's the little Things!

Configuration of the Web server continues to be a struggle for a lot of Web Connection developers and I hope this feature makes it a little easier to get your server configured in a repeatable way. I think this  script generation accomplishes two things: It makes the process easier to apply and maintain, but it also takes some of the mystery out of the Web server configuration. You now have a piece of code that actually tells you what it's doing and you can control and modify the behavior as you see fit.

With the new project changes it's gotten vastly easier to copy project files by simply 'xcopy deploying' your application. This setup script can then take a standard installation and create all the basic Web server specific configuration settings and create them for you.

The Web Connection 6.0 beta is available now to registered users of Web Connection 5.5 and later, or you can purchase an upgrade from our Web store. During the beta period we have 15% discount on upgrades.

An Updated Web Connection Add-in for Visual Studio 2015

1 comment
Tuesday, August 4, 2015, 8:31:13 PM

Visual Studio 2015 shipped a couple of weeks ago and it brings many great enhancements for Web developers with many improvements in the HTML, CSS and JavaScript editors. It  provides improved IntelliSense support that makes Web Connection and also general HTML development easier. Even if you’re not using the Web Control Framework which is geared directly at using the Visual Studio tools, there are many benefits to using Visual Studio 2015 even if you using Scripts and Templates in Web Connection, especially now that Visual Studio is essentially free for most developers via the fully functional Community Edition that has feature parity with the full Professional version of Visual Studio.

One important update that the Community addition has over the earlier Express additions is that it has full support for plug-ins. In, Visual Studio 2013 you can use the existing Web Connection add-in that was shipped with recent versions of Web Connection.

Unfortunately in Visual Studio 2015 Microsoft broke the way that Add-ins can be installed in Visual Studio. They remove community installed add-in support in the Documents Visual Studio folder, which used to be by simply copying an addin-definition into a folder and then reference the add-in from there. This is no longer support in VS2015 and so the shipped Web Connection add-in no longer works in Visual Studio 2015.

A new VSIX based Visual Studio Add-in

However – I’m happy to announce that I’ve created a new add-in that does work in Visual Studio 2015 (and beyond hopefully). You can download it  from here:

To install the VSIX, simply double click it in Explorer and the installation dialog will come up. Once installed the Web Connection add-in will show up in the Installed Extensions in Visual Studio:


To get there go to Tools | Extensions and Updates.

Building a proper VSIX Extension

The Web Connection add-in was build in the VS2008 timeframe, which is a long time ago and the code that was required to build that plug-in and the hook up code has always been a major nightmare. Hooking up commands to buttons, mapping icons and just getting the buttons bootstrapped took hundreds of lines of nasty, mostly undocumented COM code in the old add-in API and every time I wanted to make a change to the actual plug-in I dreaded having to delve into that code.

The new VSIX model is still complex, but it’s a lot easier to configure the actual hook up and integration pieces to get the add-in bootstrapped. Instead of that nasty COM code there’s now nasty XML configuration rather than code which is a bit easier. It took me only a full day to port my existing plug-in and add a bunch of useful enhancements that simplify use of the plug-in and provide some additional functionality beyond the Web Control Framework. In the process configuration has also gotten simpler and if you’re just after the quick browsing features you may not have to configure anything at all.


The Web Connection Add-in provides these features:

  • View In Browser
  • View FoxPro Source Code
  • Web Connection Web Controls Toolbox Items

Here’s what the add-in looks like when you bring it up on a Web Control Framework page:


The Web Connection menu options are available on the context menu in the text editor as well as on the Tools menu, and they are now context sensitive and only show when they are actually accessible – otherwise the options are hidden. So the Show FoxPro Code options only show when you are in a Web Control Framework page for example and either option only shows when a document with HTML tags is actually open.

View In Browser

Visual Studio has a native View in Browser feature, but unfortunately it’s not supported on custom extensions, like your typical Web Connection requests are. WCSX, WCS, WC and any of your custom scriptmaps are all custom extensions and Visual Studio doesn’t provide the View in Browser feature in this view, even in the HTML or WebForm editors.

So the Web Connection add-in provides this functionality for any page that has HTML tags in the document. For Web Connection users this means you can now browse Web Control Framework pages as well as script and template pages, the latter of which is new and improved.

This sounds like a small feature, but to me having this simple option on the menu really improves my workflow with any script-mapped pages considerably, as opposed to manually switching to the browser and refreshing.

New and Improved

The new version of the plug-in is a bit smarter about configuration for figuring out which browser and server path to use. It gets this information from the active Visual Studio configuration if you don’t configure the Web Connection Configuration settings explicitly. The add-in uses the configured Visual Studio browser that is selected on the standard toolbar, and if you are using a Web Site project (as you will with Web Connection projects) it will automatically discover the project’s Web path that Visual Studio uses to start the project.

Note that Visual Studio uses IIS Express by default to start a project and you need to ensure that IIS is started. You can start IIS Express in Visual Studio by using View In Browser in the Solution Explorer once on an HTML file which launches IIS Express and then leaves it running until Visual Studio is shut down – or you can start the project in debug mode by clicking the run button. This however, shuts down IIS Express after the debug session is done. Better to start with View In Browser of any .htm page.

Another and perhaps cleaner way to do this is by using a full version of IIS instead of IIS Express which gives the project a permanent URL that always works and you then don’t have to worry about whether IIS Express is running or not.

Show FoxPro Code

If you’re using the Web Control Framework one of the things you frequently need to do is switch back and forth between the HTML Markup code and the code behind FoxPro code that drives the actual coded logic for the page. The Show FoxPro Code option lets you do that by opening a new instance of Visual FoxPro with the appropriate PRG file opened. Here’s what you see after you click on the Show in FoxPro menu item.


Show in external editor does the same thing but uses an external editor that you can configure in web.config. I like to use Sublime Text 3 which is an excellent editor with many plug-ins for all sorts of languages. Matt Slay kindly built a FoxPro language extension for Sublime, which works great for editing FoxPro files. Here’s what you see after clicking on the Show FoxPro Code in External Editor.


Sublime is great because it’s extensible and has tons of plug-ins, is very fast, is cross platform (Windows, Mac, Linux using the same plug-ins) and has support for multiple layout windows which makes it easy to edit HTML and code in the same view.

Why use an external editor at all rather than FoxPro? One big reason is that you can keep the editor open with the file loaded unlike FoxPro which requires you to close the file in order for FoxPro to be able to compile the file (FoxPro opens the file exclusively and the FoxPro editor keeps the file open when you edit because it uses virtual editing). The end result is that the FoxPro Editor has a nasty tendency of locking the PRG file that is being edited. With an external editor you can leave the source file open and FoxPro can still compile the file. It’s very convenient for making quick edits and keeping your place between edit sessions.

Sublime is not free, but I’ve grown very fond of it and use it extensively these days for all sorts of editing and my general system editor. You can configure any editor you like though by using the configuration settings in the web.config file.


The Web Connection Add-in uses a number of configuration settings that tell it where to find files. You basically provide the paths to your FoxPro code, to the the Web folder, and the virtual/site URL to start the Web Browser.

Here’s what a typical configuration looks like:

<?xml version="1.0"?> <configuration> <configSections> <section name="webConnectionVisualStudio" type="System.Configuration.NameValueSectionHandler,System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> </configSections> <webConnectionVisualStudio> <!-- Configuration Settings for the Web Connection Visual Studio Add-in Not used at runtime, only at the design time --> <add key="FoxProjectBasePath" value="c:\WebConnection\Fox\"/> <add key="WebProjectBasePath" value="c:\WebConnection\Web\wconnect60\"/> <add key="WebProjectVirtual" value="http://localhost/wconnect60"/>
<!-- Optional PRG launched when VFP IDE launches --> <add key="IdeOnLoadPrg" value=""/>

<add key="WebBrowser" value="C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" /> <!-- The editor used to edit FoxPro code - blank means FoxPro Editor is used --> <add key="FoxProEditor" value=""/> <add key="FoxProEditorAlternate" value="C:\Program Files\Sublime Text 3\sublime_text.exe"/> </webConnectionVisualStudio>


The good news is that the Add-in doesn’t need any configuration in a Web Site Project (which is typically what you’ll use for Web Connection projects) for the View in Browser functionality, as it can determine the default browser used by Visual Studio (on the Debug button drop down) and the Web path configured for the Web site project. If you provide the values in the configuration those values take precedence, but if you leave the WebProjectVirtual and WebBrowser keys empty View in WebBrowser still works in most cases (if you’re using IIS Express just make sure IIS Express is started first as discussed above).

The Show Fox Code options require that you set the FoxProProjectBasePath and WebProjectBasePath keys and – if you want to use an alternate editor – the path to the alternate editor exe. Note that Sublime is set up by default – if you don’t want it you can blank out the value.

When Web Connection creates a new project for you, it automatically creates the relevant configuration information for you, so on new projects the configuration settings you specified during the setup process are automatically applied above.

Web Connection Web Controls Toolbox Items

The VSIX now also contains the Web Connection Web Controls which are required in order to get the Web Connection controls onto the Visual Studio Toolbox. In the past there was a registration service that allowed registration of components from a special location but again that feature has been discontinued in Visual Studio 2013 and later. The VSIX now contains the controls embedded in the Add-in DLL and they are properly and quickly installed as part of the VSIX registration.


The good news is that this is much more reliable than the past mechanism and much quicker. On the downside the location of the DLL is a deep path inside of your user settings so it’s not so obvious where the file is loaded from.

Just as a reminder – the WebConnection-addin.dll and also the old WebConnectionControls.dll, although added to your project are not used at runtime. These DLLs merely provide the placeholder controls for design time properties and configuration.

Uninstall – Reinstall

Because VSIX are essentially installers specific for Visual Studio you can easily uninstall and reinstall everything. If something breaks or the connection breaks its very quick to uninstall the VSIX and simply reinstall it.

To uninstall go to Tools | Extensions and Updates, find the Web Connection Add-in and click the Uninstall button. The add-in and toolbox controls will be removed. To reinstall simply download or find the VSIX installation file in your Web Connection installation.

The VSIX will be located in this location in Web Connection 6.0 (note this is not available yet since 6.0 hasn’t shipped yet):


Or you will also be able to download it from:

Web Connection Visual Studio Add-in for Visual Studio 2015

Going forward

For Web Connection 6.0 the configuration Wizard will continue to install the old style Add-in for Visual Studio 2013-2010, and the new VSIX based wizard for Visual Studio 2015 and later. If you’re using Visual Studio primarily for Web Connection work I highly recommend you look at using Visual Studio 2015 Community because it provides the most functionality that’s useful for Web development.

The VSIX works and I’ve been using it for the last week in development of a bunch of the new stuff for Web Connection 6.0 and creation of some of the demos for the Web Connection Training at Southwest Fox in October and for my sessions there.

But it is still a beta, so there may be a few rough spots. If you find any of them please let me know on the message board in the Web Connection section.

© Rick Strahl, West Wind Technologies, 2004 - 2017