Manual Deployment on a live Web server
Once you've developed your application and you've tested and debugged it on your development machine, the next step is to transfer that application to the server for deployment.
Deploying involves a number of steps:
- Make sure IIS is installed and base configured
- Install the Visual FoxPro runtime files for an EXE based COM server
- Copy your application project folder (Deploy folder)
- Copy your Web Files to the server (Web Folder)
- Copy any Data for your Application (where ever)
- Run Web Server Configuration Tool
- Or manually configure your Web site/virtual
- Set permissions on folders
In order to run your FoxPro application you need to have at least the FoxPro Runtimes installed. You can install the FoxPro runtime from the VFP download location by going to the following link and clicking on Download.
As an alternative you can also install a full install of FoxPro on your server. Sometimes this can be useful if you need to manually manipulate FoxPro data files or you need to debug your application. Y
Before anything else, you need to make sure your Web Server is ready to run your Web Connection application. Two things need to happen to make that work:
IIS has to be installed and configured
Since Web Connection runs on IIS (or also Apache) we have to make sure that IIS is installed. Follow the IIS Installation instructions to install and configure the base Web Server installation.
Visual FoxPro Runtimes have to be installed
Since a Web Connection server is a Visual FoxPro 9 application, you'll need to install the Visual FoxPro Runtimes on the Web Server. Either install a full version of Visual FoxPro on your server, or install a runtime only build. You can download a pre-configured runtime installer from Christof Wollenhaupts FoxPert Web site.
Because Web Connection projects contain a single folder hierarchy, you pretty much can zip up your entire application folder tree (
web folders) and push that up to the server and unzip there.
If you are using a new project in Web Connection 6.0 or later you can also use the
build.bat file in your project's root folder to build all the distribution files into a self-contained Zip file you can copy to your server.
The batch file copies all the required Web Connection dependency DLLs alongside your exe and startup INI files.
datafolder (if it has something in it)
You can optionally add additional folders to this zip file as needed.
The following section describes how to manually copy these files.
However, one thing missing from such a simple folder copy, is the collection of dependent DLLs that Web Connection uses. These DLLs live in Web Connection install folder but need to be copied into the
Deploy folder before you build your final install for the server:
The simple install often is sufficient but if your project is more complex or you want to break up your Code and Web folders into separate repeatable packages, you can use the following steps.
New Web Connection projects include a
build.bat file in the root folder that create a combination of your
deploy folder, plus the required DLLs in a generated
build folder which is suitable to deployed to a live server.
Your Web Connection project by default depends on the Web Connection installation for various dependencies and DLL files as outlined in the previous section.
From Web Connection's perspective, the deploy folder typically only needs a few files:
Add to that any explicit dependencies that your application has if any. Extra configuration files. Data Files etc.
To help with collecting dependency files and to build a repeatable, deployable
Deploy folder, a
build.bat file was created in the project root. When you run this batch file it'll copy all the dependent support files from the Web Connection installation folder, plus your compiled EXE and INI files into a
Build folder. The batch file also zips up all those files for you (if 7zip 7z.exe is on your path).
If you have additional files or folders you need to deploy as part of your application I recommend you add those to the build folder or better yet you add the commands to copy the files in
build.bat to copy them as part of the script that creates the final
\build folder. You can zip up all files in this folder, upload to the server and then unzip them back into the
Once you've zipped up all of your code files you can send those to the server and make sure to unzip them into the
Deploy folder of your project. Keep in mind that the project structure is important so the
Web folder names are significant.
Depending on how you packaged your code files you likely just unzip the file into your
Deploy folder after which you should be ready to run your main EXE file.
The Web Connection handler includes a file upload option that allows you to upload arbitrary files to the Web server, which can be a great way to push files the server without requiring installation of an FTP server. For this to work you first have to publish your Web Folder so the module is present (see steps below) and you'll need to modify the .config file to allow large file uploads.
At its simplest you can simply zip your
Web folder and send that up to the server and unzip it there. That works fine for a one time install. You can use Remote Desktop File Transfer, a DropBox/OneDrive file share, or any number of other ways to the get files up there.
However, more than likely you'll also want to update Web files frequently as you modify your application and for that you typically will want to use an FTP server or IIS Web deploy to allow for individual or incremental updates of server files.
If you use Visual Studio, you can use the Web Publish feature and Web Deploy on the server to push files from your machine to the Web server. Web Publishing uses either FTP or IIS Web Deploy to publish your entire Web site or individual files or folders to the Web server. Web Publish supports incremental updates of projects as well as allowing to publish individual files quickly and easily right out of Visual Studio.
If you're using Web Connection Scripting Pages (via
Response.ExpandScript()) make sure you don't publish your PRG or FXP files in your Web folder. When script files compile they embed hardcoded paths into the PRG and if paths change the code will break. Either let the files auto-compile or if you're running pre-compiled scripts use the admin page Compile scripts option to compile your scripts.
Once you've uploaded and set up your
Deploy code and
Web files, you need to configure the Web Server for your application. Make sure that IIS is installed and configured on the server, and that any Web site you plan to install on exists before you start.
Then simply run the following from an Administrator Command Prompt:
MyApp is the name of your server application.
If configuration of your server is different than your local dev environment - different virtual/root setup or different folder structures - you'll need to adjust the configuration for the script which is contained in the
YourApp.inifile setting next to
[ServerConfig] Virtual=wconnect ScriptMaps=wc,wcs,wcsx,wwd,wst,md,blog IISPath=IIS://localhost/w3svc/1/root
You can change the Web Site by changing the IISPath and the ID (the number before
/root) and matching that to an IIS Site id you can find in the IIS Manager. You can change the virtual folder name, or leave
Virtualempty to specify a root Web site.
If for some reason the automatic configuration does not work, or you're running an older pre-v6 server you'll need manually configure the server. To do this you need to perform the following steps:
- Create an IIS Application Pool (see)
- Create the IIS Virtual Directory using the Application Pool (see)
- Add Windows and Basic Authentication (see)
- Create ScriptMaps for
- Create Temp Folder Permissions (see)
- Lock down the Admin Folder
For the FoxPro Application:
- Register your EXE as a COM Server with
MyApp.exe /regserver(Admin required)
- Copy data directories and make sure paths are referenced
By default your Web Connection configuration should be complete at this point and you should be able to run your application.
If you have any custom configuration settings that depend specifically on the environment - email servers, passwords, special paths etc.- in your configuration files you should make those changes now.
These changes typically affect
MyApp.ini for your FoxPro server configuration, and
web.config for the Web Connection handler configuration with the latter rarely having to change.
At this point your server should be ready to run. I recommend you start by testing your application in File Mode first. Make sure the the
MessagingMechanism=File to start.
To test, run your server by simply double clicking the EXE in Explorer or running from the Command Prompt. If all goes well the server should just pop up.
If you manually configured or aren't using a new-style project layout, make sure your temp path, template and all the paths in
wc.iniif using ISAPI) match. Specifically make sure the
Next you should navigate to the Web Connection Administration Web site and go to the .NET Handler page:
and just verify that the settings there look OK. If you had your development environment set to COM you might want to switch to file based to verify that the server works first.
Hit any of your application links that use your custom script map.
Windows Server by default locks down local logins using
localhostor any other local IP Address which means you can't authenticate using Windows Authentication. To work around this log on from a remote machine or follow the steps outlined in this help topic.
Pay special attention to the Security section on the bottom of the .NET Handler Admin page, and verify that user account the server runs under is what you want to use. By default this should be SYSTEM which is determined by the User Identity on the IIS Application Pool. If you want to use a different user account you need to change the Application Pool User Identity in the IIS Management Console.
And you're good to go! You're application should be ready to run!
See alsoServer Configuration Wizard | COM Server Configuration
Comment or report problem with topic