Hi Rick,

The post subject says it all. I'm a bit confused as how to best debug this. I know I've mentioned some odd behavior to you when ASSERTS are turned on, which is my normal operating mode, so I have also turned that off for the purposes of this testing.

Using the old sledgehammer I've set a breakpoint in the liveReloadServer.HasFileChanged method as well as the initial method just so I can step through things. The file watcher appears to load and I end up in the application READ EVENTS loop. I edit a prg in VFP by adding some characters to a comment line, click the save button in the standard VFP toolbar, and the server does not magically restart. FWIW LiveReload did work for me in 7.x but I can't say that I recall it working since I upgraded to 8.

On a side note, I also noted that when I use the Status form to toggle the Live Reload setting and then click the Save Server settings button I am getting the following error:

This happens 4 or 5 times. I ignore all of them and get the settings saved confirmation. When I check the application INI it is properly updated.

Anyway, time to call it a week. If there's a better/more efficient way to troubleshoot, please let me know at your convenience.

P.S. One clue I just noticed. I just found all this stuff at the bottom of my INI and I don't recall what this is supposed to be, particularly the whole [Dotnetbridge] section?

[Bridge]
Clrversion=v4.0.30319
Errormsg=
Error=Off
Throwonerror=Off
Usecom=Off
Lastexception=NULL
[Dotnetbridge]
Reateinstance_oneparm=NULL
Reateinstance_threeparms=NULL
Rror=Off
Nvokemethodasync=NULL
Sthrowonerrorenabled=Off
Oadassembly=NULL
Oadassemblyfrom=NULL
Astexception=NULL

You need to disable Debug Mode if you don't want to break into code on errors. Debug mode stops on any code errors and for live reload to work best you don't want that - rather you want your app to generate an error message and hopefully you can fix the error based on the message.

If you do need to debug your code interactively at some point you enable the debug flag, then run your debug cycle. When done reset the debug flag to off.

+++ Rick ---

Interesting... I've been running in my dev with DebugMode ON since the beginning and in the past LR has worked, albeit with some interaction with ASSERTS that I never spent the time to try and figure out. I will try your suggestion and figure out what works better for me. Thanks!

No change when setting DebugMode off. I may add some logging so I can at least see what happens when LR is invoked. Using the VFP debugger with this is way too tedious...

I double checked my set up and it looks to me that it's all working.

Make sure you enable Live Reload on the server too - that's what causes the page to refresh. The FoxPro code reload is handled from the FoxPro app, the HTML reload is handled via the handler on the server but it has to be turned on.

For the Foxpro server the setting is on the status page

...but when you flip the switch on the server for local work it should do them both (assuming you have the permissions to write to the config files in both places).

The fact that your configuration is blowing up is a red flag which likely means the FoxPro INI file setting is not getting written or read (the wwConfig code) - that should not be failing unless there's a type problem (maybe you renamed the config class or the class is not loaded?).

Those settings you have in the INI file look wrong and there are values in there that look like they're objects and that surely will not work.

+++ Rick ---

Poking at this a bit more today. After re-reading the comments in the LiveReloadServer.prg I thought to check the web.config file. It was not enabled there so I thought that's my problem.

I then enabled it. You can also see my custom extensions. (See above.) FWIW I do not have the bit related to html files uncommented even though I apparently have that extension in the list.

I double-checked the INI file and verified that it was On there as well.

Fired up my dev console, hit it with a request just to make sure it was running, made a minor change to a comment in a prg and saved. No live reload happened. I also tried adding a simple variable declaration and saved just in case LR is smart enough to recognize that all I changed earlier was a comment. Still no joy.

On a side note, I brought up the Status form from the console button and used that to turn off debug mode. When I clicked the Save Server settings button I got this:

The VFP debugger shows this:

And it just gets weirder. I then noticed that when I launch my app console, it immediately fires off 4 requests without me doing a thing in the browser.

I then disabled LR in web.config and those phantom requests did not fire. Turn it back on; every time the console is loaded it fires off 4 requests.

I'm sure this is just something wonky in my environment but what that bit of wonkiness could be is yet to be determined. Maybe I'm picking up the wrong version of some DLL...

That's because that's a method not a property. Why are those [Bridge] and [wwDotnetBridge] in the configuration? Those are basically properties and methods of the wwDotnetBridge class and they don't belong there.

My guess is that you attached some objects to the configuration object which you should not do. That's not a place to attach other worker objects. Use the wwServer instance or the oCache property to dynamically attach global objects and properties (use ADDPROPERTY() to avoid COM Type Library bloat/recompiles)

*** In OnInit or OnLoad
ADDPROPERTY(goServer,"oDotnetBridge",GetwwDotnetBridge())
ADDPROPERTY(goServer,"oAppUtilities",CREATEOBJECT("MyAppUtilities"))

You can then use them anywhere in process code:

Server.oDotnetBridge.InvokeStaticeMethod("...","")

If I did something like that it was not on purpose. Here's the really dumb question; how would I figure out if I've done something like what you've described? Based on what I'm seeing in my dev environment those sections are getting added back magically by processing a request.

Scratch that last bit about it getting added back like magic. I was looking at a different INI. But the firs question stands. 😃

I don't think you're looking at the wrong file because the error and stack show that it's those properties that are failing...

If I had to guess you have one or more objects attached to the global configuration class (in yourAppMain.prg at the bottom) - if the values come back when you delete them and then save your settings.

+++ Rick ---

I have the usersecuritymanagerprocess object attached to my main object. On my dev system I also have a help process but I think based on some changes you made I don't need that anymore...

FWIW that error fires 5 times when attempting to save server settings, presumably once for each thing it thinks should be there but can't find, and the INI setting is properly updated.

FWIW here's the call stack:

Just look at your configuration object. that's the issue... forget all the rest. Look at the property that is failing and that will be your key on what to look for and get rid of.

+++ Rick ---

That timer firing inside the VFP debugger is going to drive me nuts...

Something is adding back those Bridge and Dotnetbridge sections and the properties for the latter are getting munged:

[Dotnetbridge]
Reateinstance_oneparm=NULL
Reateinstance_threeparms=NULL
Rror=Off
Nvokemethodasync=NULL
Sthrowonerrorenabled=Off
Oadassembly=NULL
Oadassemblyfrom=NULL
Astexception=NULL  

Set the timer to some very large number temporarily.

or turn it off in code before you hit that code.

+++ Rick ---

So I fixed the property names in the Dotnetbridge section that shouldn't be there and saving settings works. Now back to the primary conundrum which is getting LR to behave. Figuring out how that section gets in there is another mystery to be solved.

OK, I figured out why I added oBridge at the app level. I use dotnetbridge to use that custom DLL I wrote that updates JPG orientation.

Best I can tell at this point is the properties for the Dotnetbridge section get munged when the Save INI method runs out of the Status form. I almost never use that option and will avoid it in favor of editing the INI and web.config files directly.

Am I doing something wrong by loading my custom DLL when the server starts up? Because it has to be invoked via dotNetBridge I made the assumption that doing it once when the server starts was better than on demand.

I know you're probably sick of this thread but I just saw LR work as expected by editing the PRG in an external editor. I could swear I'd seen this work directly in the same VFP session in which I've got the console running? OTOH it did not work for one of my template extensions defined in the LiveReloadExtensions key in my web.config. Am I confused about how that works?

FoxPro and HTML/Template editing are handled by different bits. FoxPro code is handled inside of FoxPro via wwDotnetBridge and a File watcher. HTML and templates are monitored by the .NET Module and a WebSocket that notifies the site.

You need to also make sure WebSocket support is enabled in IIS (Web Connection installs that by default).

Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebSockets

Look at Install-IIS-Features.ps1.

+++ Rick ---

Thanks. As this is a dev setup I created 4 1/2 years ago I would not have gone back to that script with new framework releases. Are you suggesting the install script should be re-run? Having asked the question, I was able to verify that the IIS-WebSockets feature is enabled by running this:

 Get-WindowsOptionalFeature -Online -FeatureName "IIS-WebSockets"

Make sure your scriptmap is in the script map list. Check to see if you can edit an HTML file.

+++ Rick ---

Here's my extension list:

r3 is my primary scriptmap. Editing an .r3 template in VSCode and saving is currently not triggering LR.

Also, maybe I'm confused on the expected behavior when editing a non-VFP bit of code. When I edit a prg, I see the console shutdown and fire back up. I've just been assuming that editing any file that should trigger the LR will do the same thing. Perhaps that's a bad assumption?

When I edit and save an htm/html, css or js file, I see a new request fire in the console. (Actually, I see multiple requests after the save.) When I edit and save an r3 file, I do not get any new requests.

I'm coming to the conclusion that there's something odd about the way we have our r3 templates configured that messes with LR. Just about every other file extension that's in my list ends up triggering new requests.

Yes that's a bad assumption. There are two separate file watchers as I explained in a previous message.

FoxPro files are monitored by the Web Connection Server and it monitors only files that should force the FoxPro server to restart. ie: .prg,.vcx,.exe,.app,*.ini

Web files in the Web Folder are monitored by the Web Connection module and it looks for specific extensions (plus a few custom ones that let the FoxPro server trigger a refresh) to cause the Web page to be refreshed. Web pages are refreshed via Web sockets with some injected HTML that has hosts the Web socket, which the module code fires.

If it works for HTML pages, then Live Reload is working. If it doesn't work for your extension, check the browser tools and see if there are some errors - perhaps there's something odd in your HTML pages (like a missing </body> tag) or something that causes the injected code to fail (or not to inject).

All of this depends on a file watcher and assumes your files are located in the Web Root folder or below it. If your files live somewhere else live reload doesn't work. I suspect that's the problem actually based on the consulting meeting we had last month.

+++ Rick ---

Always good to learn new things and have the veil of bad assumptions lifted from mine eyes. 😃

The pathing bit was the clue for me. The r3 files do not live under the web folder hierarchy. They are in a folder which is in the same folder hierarchy as deploy and web so that answers that question. I'll have to think through the implications of moving that folder if I want them to be LRed.

It's still a bit odd to me that the LR often triggers more than one request but I'm sure it's due to our non-standard use of the template model. Another assumption...

Thanks again for taking the time, Rick. Much appreciated.

Multiple request triggers likely occur due to authentication. You might want to run Fiddler and check what those extra requests are doing when they come in. I suspect some of them may be 401 auth requests or OPTION requests on API calls.

+++ Rick ---

Not real familiar with Fiddler or how to use effectively. I'll see if I can tap an internal resource.

You can also use the Network tab in the Browser Tools and use Preserve Log to capture multiple requests.

+++ Rick ---