Hey gang, I'm getting into WC again after a long time away — WC 5 is the last time I used WC.

Can somebody please confirm that WC 7 works on Windows 7 Pro?

I ask because, I'm stumped. No requests are getting to WC. I've resorted to granting IUSR "Full Control" to the application folder and the temp folder, and still nothing appears to make it through. Here the "applicaion" is just wcDemoMain, the samples.

One variant that may be a problem: I installed into a folder named C:\wc7, not C:\wconnect. My c:\wconnect folder contains legacy I am loathe to touch, the Foxpro Wiki depends on that 😃

One clue: when I test my new (local) virtual under IIS, with the "Test Settings" button, that fails with "Invalid Application Path" when I'm the "Application user". When I "Connect as..." me, the root admin user, the test connection works.

So it's a permissions issue. But I've already granted IUSR the keys to the city.

Other than that, I'm on a VM on a Mac. That shouldn't matter because everything here is local to the VM.

Of course, I've rebooted the OS. That actually used to work reliably for this problem.

Clarification: not even default.htm is being served. http://localhost/wconnect/ returns a blank page, no IIS error, nothing.

So yes, I'm stumped. Any ideas?

**--** Steve

Steven -

Are you using the .NET module or the older ISAPI module (wc.dll)? It may be an issue specifying the Temp folder location, which is done via web.config for .NET or wc.ini for ISAPI. You may be setting the path in wc.ini but that isn't used by the .NET module.

There is some good troubleshooting information here..

Troubleshooting a Filebased Server Install

Also the folder permissions should be based on the Application Pool user account..

Temp File Path Permissions

- Mike McDonald

Thanks for your reply, Mike.

How would I know which I am using? The .NET module or the older ISAPI module?

I'm just trying to get wcDemoMain to return samples...

Can I just say something, to clarify? I want absolutely minimum involvement with Windows and .NET. I consider these things to be unclean, and nasty. I'm just not a Windows user anymore, except for VFP.

All I want to do is fire a GET request, which will run a VFP SELECT on server-local data, and return a JSON string. Peace, out, if you know what I mean. I neither need nor want anything related to .NET happening at all. F*k .NET...

So I'm guessing I want the older ISAPI module? Is that right?

I sort of feel there should be a sidebar in the WC Getting Started docs that say, if you want to avoid effing around with .NET, do this: Step 1...., Step 2...., ....

Steven -

The "Web Connection Module Administration" page would show what you are using, under "DLL Version", and you can also see which config file is being used. The link for that page would be like http://(your_domain)/(your_virtual)/admin/ModuleAdministration.wc and it is linked from the /admin/admin.aspx page.

You probably still want to use the .NET module instead of the old ISAPI module, since the newer version has better management features and error handling. Either way, you won't have to 'use' .NET yourself. It is just a matter of whether WC & IIS will use webconnectionmodule.dll (for .NET) or wc.dll (for ISAPI). Nothing changes on the VFP side no matter which module is in use.

- Mike McDonald

Hi Steve,

First - it'll work on Windows 7. If you use the .NET module you will need to have .NET 4.5 installed but if that was the problem you'd fail hard (and if you're on Win7 as an old install you almost surely have .NET 4.5 installed anyway by way of other apps).

So first, permissions have nothing to do with .NET or ISAPI those are specific to the OS and IIS. Generally speaking set up the application to the account you want then add permissions for that account to your project folder (both Web and Code). Add the IUSR account with read/execute to the Web folders. Remove the IUSR account from the Admin folder.

FWIW, all of this is now done automatically if you use the new project features that can auto-configure projects and that configuration code compiles into the project so you can also run it on the server. You likely have an existing application, so that doesn't apply but worth looking into (more below).

What did you do to install or setup? If you use the Web Connection Setup it should set all the permissions that are required.

If you manually set up your project and configure take a look here:

IIS Configuration

404's can come from many sources - basically IIS throws 404s on missing features (like ISAPI support not enabled, or ISAPI extension not marked as safe). Many of these have to do with ISAPI issues and that's the main reason Web Connection has moved away from ISAPI a long time ago (although it's still works).

ISAPI was always a bitch for me to maintain, and the .NET Module is drastically easier to run and maintain and add useful features to. Like the recent live reload socket server that's integrated directly into the module - that would never have been possible with ISAPI (at my C++ skill level anyway 😃.

IAC if you're using Web Connection now I would highly recommend you use the .NET module both for stability, ease of deployment and portability in general. As Mike said - you don't need to interact with .NET code directly in any way (although there are other parts like JSON parsing and a few other things in the framework that use .NET internally).

In fact, even if you have an old project you're moving or updating I would recommend looking into setting up a new project if not for your project itself then just to a) test to see if that all works, and b) to see how a new project is setup and how the build/run/package features work. It might be worth moving even an old project into that basic setup which involves primarily reconfiguring your startup program file.

Anyway - the doc ref'd above has all the things you need to for site configuration including permissions and special config settings you have to make for proper registration. If this doesn't do it for you, ping me on Skype and I can walk you through it.

+++ Rick ---

Thanks for the reply, Rick. Getting back to this now.

I just made a fresh installation of .NET Framework 4.8 and this appears to make no difference.

One evidently clear hint, when I try the "Powershell IIS Feature Installation" in an Administrator-level Powershell window, it just fails spectacularly with The term 'Enable-WindowsOptionalFeature' is not recognized as the name of a cmdlet, function, script file, or ... followed by several screenfulls of others.

Can we start with that? Why would this be?

Windows 7?

I think that functionality was introduced in Windows 8.1. Looks like you'll have to go through the interactive process.

Manually installing IIS Features

I think that functionality was there in Windows 7 via dism.exe but the feature names probably wouldn't exist anyway.

+++ Rick ---

If the docs were on Github, I'd submit a PR to bracket that bum steer.

Windows, particularly IIS, is such a shitshow.

I updated the docs. I don't actually know what version these admin features start working in and looking for an answer online I don't see that anywhere...

Then again what do you expect when you're running a 10 year old OS? Web Connection still works, but things in the OS will change in a 10 year time span.

+++ Rick ---

Windows 7 is either supported, or it isn't.

Update:

I've been through all the manual setup steps. I still haven't seen any request to the sample app make it to the WC form.

Requesting http://localhost/wconnect/admin/ModuleAdministration.wc in the browser works, sort of. Evidently no CSS is being served. The error for that is, Resource interpreted as Stylesheet but transferred with MIME type text/plain: "http://localhost/wconnect/lib/bootstrap/dist/css/bootstrap.min.css". The network tab shows Uncaught ReferenceError: $ is not defined which is a missing jQuery reference. Of course, none of the samples work on this admin page.

IIS is a complete fucking shitshow.

I see no evidence whatsoever that WC 7 works on Windows 7 when it's installed in the non-default folder.

That sounds like the Static File Module in IIS isn't installed.

Ping me on Skype and we can take a look.

+++ Rick ---

If you're running under the Application User Account (or whatever that's called) you have no rights and that's not recommended under any circumstances. To get things going I recommend SYSTEM for the AppPool, and you can dial back once things are running (I like to use NetWork Service).

The Web Connection install will set permissions on folder and should set the right permissions on the virtual as well.

It's true I don't test for Windows 7 (or 8) but the underlying architecture of IIS configuration hasn't changed since V7.0 came out with Vista so the process is identical. But if there are missing components that can fuck everything up.

Again, if you want contact me and we can take a look - I'll be happy to help and maybe we'll find something that doesn't work, but my guess something is missing in the install bits or as you say the permissions are all wrong. But if you use the default installation or new project Wizard those settings should be made for you and you shouldn't have to change anything.

+++ Rick ---

So I tried this out on my Windows 7 Virtual Machine, and I got WC to install into a c:\WC7 folder without a problem. Note that WC7 installs in place for the demo - there is no Web folder to copy to.

There are a few oddities with the help file (due to the ancient IE engine version but it does eventually come up). Other than that the install ran, and the site came right up. Now I did previously install IIS so it was set up properly already but that should match the settings in the help topic.

I did have a problem because this is a pristine install (ie. very little ontop of the base install). The site wasn't working because the .NET version by default is 4.0 which is too low and is not finding some dependencies needed by Web Connection. It needs to be at least .NET 4.5.2. So installed latest version of .NET Framework and then both IIS and the Fox application ran without problems at this point.

Also I was just thinking about your hatred for IIS - why don't you install IIS Express instead locally? Small self-contained install, no permissions requirements (it runs under the local user) and doesn't need any special installation other than running the installer. That's easier to deal with for most scenarios anyway. I used IIS Express for the new project I created (ie. no IIS configuration for that application) and it just runs out of a folder. If you've configured for IIS, you can also jump back and forth between the two with DO LAUNCH or DO LAUNCH WITH "IISEXPRESS".

Note the built-in new project wizard creates a configuration script for you that will configure your server for IIS. If you compile an EXE you can run MyApp.exe CONFIG and it'll run the config, with the setting specified in MyApp.ini.

+++ Rick ---

So I uninstall EVERYTHING related to IIS and everything related to WC (all folders, all shortcuts). Then I reinstall IIS, gimme everything FFS, clicking all the checkboxes in the treeview, I'm done with fucking around.

Reinstall WC from scratch. Then Do launch, and holy cow, an actual readable, formatted web page comes up.

From there, however, still nothing works.

But at least now I'm getting Configuration Error web pages, as opposed to nothing at all, in the browser. The errors complain about .NET defaultLanguage="c#" targetFramework="4.6.1" in web.config, a .NET version that is not installed on my machine. I have .NET Framework 4.8 installed. I know this because I went through the comically ridiculously buried procedure in the registry to find out, what .NET versions do I have on this machine?

Finally I get my first request to show in the WC form after I change the application pool from DefaultAppPool (wtf?) to West Wind Web Connection.

Therefore a fresh Web Connection installation, into a non-default install folder, given a deluxe everything-installed IIS, fails to set the proper application pool on the webconnect virtual, and sets an apparently bogus .NET framework version value for configuration -> system.web -> compilation.targetFramework in web.config in that virtual. I'm not sure the latter matters once the application pool is set up properly.

So everything is now working on this one, particular laptop.

Thanks for your patience, Rick. This certainly taxed mine. Apache and related config is heaven compared to this. I'm never going back to Windows.

The Target Framework version is a 'minimum' version so anything above that will work - I run 4.8 here and that works so that should not be a problem. I use 4.6.1 because that's what server 2012 R2 installs by default and is meant to be the minimum that Web Connection should run on.

The minimum version is required because without it some of the new features like the WebSocket support will not work as they need to know these features are available to access. The default is 4.0 and that wouldn't work with the WebSocket library. So there has to be a value there and 4.6.1 is the realistic minimum value.

FWIW, these are new due to the added WebSocket support for the Live Reload functionality... But from what you're telling me here, I don't think this is part of the problems you are seeing.

I change the application pool from DefaultAppPool (wtf?) to West Wind Web Connection.

That definitely will be a problem if the DefaultAppPool doesn't have the right permissions (ie. no read/execute and write access in the Web folder).

So I can verify that this indeed a problem. Looks like it's a timing issue - the Application Pool gets created but apparently isn't ready to be bound yet. After a clean install (removed Web Connection AppPool) and then reinstalling, I also get:

Same as what you describe. The Web Connection AppPool is created but not assigned to the virtual. If I re-run the setup a second time though, it uses the proper app pool.

Not quite sure what's happening but I suspect a timing bug. I actually have dealt with that very issue a few versions back, but I'm pretty sure on Windows 10 and recent servers it works correctly because I've installed a number of servers from clean room installations without issues. I'll have to look at this again and see why this would fail on older servers. Maybe a hanging ref or simply giving it a few second or two between creating and assigning the AppPool.

Anyway - I'm glad you did get it running and thanks for following this up so at least I can fix it for future cases.

+++ Rick ---

Just a quick follow up...

So - it turns out there definitely was a bug with the app pool generation logic when no previous app pool exists. First run fails, subsequent runs works. It turns out it's a timing bug and adding a small delay fixes the issue.

I've updated the Console and the support file. If you're interested you can either re-download the registered package in full or grab:

https://west-wind.com/files/WebConnectionExperimental.zip

This zip file contains just the updated Console.exe and wwWebServer.prg. If you're using the new config features the prg is needed for the auto-configuration with MyApp.exe CONFIG option.

Steve, thanks for your help. This looks like it's been in there for a while, but surprisingly I haven't heard anything about this issue before 😦 Hard to track on my end because I always have an AppPool installed. Even on new servers I tend to run multiple installs so if the first one fails it may have gone unnoticed.

Anyway fixed now.

+++ Rick ---