Now that I have Vultr running my Web Connect 3.0 application, I'm finding that my application which has always run in File Mode dies every few days after Windows Reboots. I'm assuming that Vultr is updating Windows and forcing VFP to end.

Back in the 1990's running in COM was a lot more technically difficult or at least that was my (lack of) understanding. I have Rebuilt my project and it running fine in File Mode. After switching to COM and from the Admin page Loading Servers, I see two WC Consoles but can't get hits to process. The hits are in the /TEMP folder but COM it not picking them up.

Any suggestions how to fix COM or am I better off to create a windows startup script?

BTW - Found a bug in wwUtil (version 3.x) DOEVNETS is not allowed to have parentheses "DOEVENTS()" on line 1185. I guess I'm a bit late to report to you. LOL

If you're running in file mode and interactively in a Windows sessions I think your Windows interactive session (or Remote Desktop session) - is shutting down.

Make sure you test your application without a login and you can set auto-start up for file based applications.

But not sure what works exactly for the 3.x ISAPI handler, since most of those features were introduced in later versions.

The event log should tell you when the machine gets rebooted and why. Windows Server won't auto-update unless you explicitly told it too, but interactive sessions will shut down when they're idle I believe and that's most likely the reason for your problem.

+++ Rick ---

After several hours of trial and error testing, I have not been able to get COM to work and the File mode which is started from the Web Connection Module Status Page also does not respond to hits which are showing up in c:/temp folder. Yet when I run the app from with desktop VFP, the hits all get through just fine.

After running myProject.EXE CONFIG, I noticed in Task Manager one server was running. I tried hitting one of the pages in my app and surprise, it worked. No WC Console was showing but I did notice the User account that started my project was SYSTEM.

Then I returned to Web Connection Module Status Page and Loaded One Server. It showed up in the Task Manager under the logged in user account (my duplicate administrator account). As I continued to hit web pages, my application continued to respond but none of the hits were being processed by the version I loaded, rather the hidden version that was running in SYSTEM user account.

Any suggestions...?

LOL! It's a good thing you don't listen 😃

I told you that when servers are auto-loaded (via COM or Autoload in File Mode) they don't run under the desktop account. They run under the launching IIS Application Pool account. If the Application Pools is set to SYSTEM, things are likely to work because you'll have the rights to read/write anywhere on the machine. If it's something else you'll have to set the appropriate permissions...

The differences you are seeing is because you are running your server using the INTERACTIVE user that's logged on to the Terminal session, vs. the application running in the context of IIS in the Application Pool.

+++ Rick ---

Yep, listen but don't understand is more like it!

The Application Pool is set to LocalSystem as described in the write up you published in December 2019 "Deploying and Configuring West Wind Web Connection Applications".

And when I Load Servers, they show on the desktop but don't get the c:\temp\wc files. This is true for both COM and FILE modes.

Additionally, the article suggested creating aa alternate Administrator account and disabling the default Administrator for security reasons. This was also done and the alternate account is part of the Administrator Group.

I don't understand "Terminal session, vs. the application running in the context of IIS in the Application Pool" or what adjustments are needed to get the Remote user to start in the correct identity.

Where do I go to set Application Pool correctly? Do I create a custom account and point to my alternate administrator...? That seems like if the machine were to reboot the site would be dead until I logged in again!

Files go where you tell them to go in wc.ini or web.config or webserverconfiguration.xml (depending on which tech you use). Either you're not setting the value, or the permissions are not set.

COM doesn't use files for messaging so you wouldn't see any files no matter what (except for the Error file).

+++ Rick ---

It was the permissions, I kept looking at the permissions of the c:\temp\wc folder and only after looking at another operational site did I realize the myProject.EXE must have the Interactive permissions set with full control. Now both FILE and COM are responding.

Only thing I don't have going is the WC Console on the desktop. I can live without it but must admit knowing what is going on while I'm logged in would be nice. Any tips?

Before you comment on "tips" above... OOPS!! I tried to save the configuration file from the browser UI and it overwrote the web.config file with zero bytes. All the configuration stuff is gone. Glad it is a holiday weekend and to hot to go outdoors, aren't computers fun!

I think you have that backwards. INTERACTIVE is the account when you are logged on.

You will not see an interactive FoxPro window if any account other than INTERACTIVE is used by IIS or DCOMCnfg. Server still runs - it's just not visible.

Interactive only works if the Foxpro server is explicitly (for COM) configured for INTERACTIVE in DCOMCNFG. Otherwise the server will run invisibly.

Interactive only makes sense if:

• You are always logged on! (and I mean ALWAYS! not auto-logged off)
• You're running file based
• You have the FoxPro server DCOMCnfg set to INTERACTIVE

Running in COM with anything but DCOMCNFG to INTERACTIVE never shows an interactive FoxPro window.

You should never run as Interactive except when testing. And even then you can test in file mode and manually launch the EXE which then runs as your current user.

You should be logged in with the Username that you log in with and that's the INTERACTIVE user. You can also set INTERACTIVE as an account in the permissions and that should also work when logged on but only when you are logged on, not when launched from IIS without Impersonation.

Make sure you don't register your FoxPro COM server for Interactive on the server in DCOMCNFG. If you do that it won't work unless you are logged on. Ideally you should not use DCOMCNFG on your COM server at all unless you use a custom account, and if you do, assign permissions to that account for the entire machine and not the server in DCMCNFG. For starters use SYSTEM or a local Admin account, and it should work without any DCOM configuration.

+++ Rick ---