Unfortunately the same cannot be said for server side code. When making changes to script pages in Web Connection I make a change, then manually flip over to the browser to review the change. While it's not the end of the world, it's much nicer to have a browser side by side to my editor and see the change side by side.
File monitoring is easy enough. A file system watcher monitors the file system for any changes to files you specify via a set of wildcards typically. If any of these files are changed the watcher will kick in to perform an action.
Depending on what you care about this can be as simple as simply reloading the page, or in the case of actual code files requires a rebuild of an application.
ASP.NET Core actually includes a built-in file watching tool called dotnet-watch which you can run to wrap the dotnet run command. But it only handles the recompilation part, not the browser refresh.
The other part of the equation is refreshing the browser. In order to do this any tool need to load the browser and inject a little bit of code into each page loaded in the browser to essentially communicate with a server that allows reloading the active page. This typically takes the form of a little WebSocket based server that runs in the Web page and communicates with a calling host - typically a command line tool or something running in developer tools like Browser-Link does in Visual Studio.
Luckily we don't have to rely on Microsoft to provide a solution to this. There are a few tools out there that allow browser syncing externally from the command line or via an admin console in a browser.
The one I like best is Browser-Sync. Most of these tools are nodejs based so you'll need Node and NPM to install them, but once installed you can run them from the command line as standalone programs. Browser Sync does a lot more than just browser syncing.
As is common with many Web development related tools Browser Sync is built around NodeJS and is distributed via NPM, so make sure NodeJs is installed.
This installs a global copy of browser sync which can be run just like an executable that is available on the Windows path.
Note the --proxy localhost/wconnect switch which tells browser-sync that I have an existing Web Server that's running requests. Browser-Sync has its own Web Server and when running NodeJs applications you can use it as your server directly. However, since Web Connection doesn't work with Node I can the -proxy switch to point to my application's virtual directory which is http://localhost/wconnect/. If you're using IIS Express it'd be --proxy localhost:54311. The proxy feature will change your URL to the proxy server that browser-sync provides, typically localhost:3000.
Browser sync automatically navigates to http://localhost:3000/wconnect and opens the browser for you.
Now go to the No Script sample at wcscripts/noscripts.wcs page and open it. Next jump into your editor of choice and make a change to the page - change title to Customer List (updated) and save.
Now go back and remove the change... again the browser refreshes immediately.
Et voila, live browser reload! Nice and easy - cool eh?
lcFiles = "**/*.wcs,**/*.wc, **/*.wwd, **/*.blog, css/*.css, scripts/*.js, **/*.htm*"
As of Web Connection 6.50 new projects auto-generate a browsersync.prg file into the code folder, so if you have BrowserSync installed you can just do browsersync to fire it up and open your site on the proxy port.
Browser sync works great for any content that lives in the Web folder structure. Unfortunately the process class lives in a separate folder hierarchy and can't be monitored there. Even if you could - the Web Connection server has to be restarted in order to see changes to the process class as those classes are not unloaded.
So for 'real' code changes you're still going to have some manual cycling time. But that's probably OK. The time consuming stuff usually revolves around the fiddly HTML and CSS manipulation and that's where browser-sync can really help make you more productive.
I've been using Browser Sync for a while now and while it works pretty good it does get 'stuck' every once in a while. It usally starts by the browser taking a long time to refresh a page or navigate to a new one. It doesn't happen very often, but it does happen enough to mention it here. Incidentally I see the same thing happening with the WebPack dev server in Angular. These tools are pretty hacky in how they intercept traffic and refresh so I'm not surprised that the Web Socket connection gets flakey in some situations. In fact, I'm rather surprised how well it works if anything.
Once I see the browser navigating slowly or refreshing really slowly I simply kill the console window that's running the browser-sync code and I re-run DO browsersync from the FoxPro command line to start a new instance.
Again, it's not a deal breaker, especially since it drop dead easy to stop/restart.
Browser syncing may not sound like that impressive of a feature, but I have to say that it ends up changing the way you work. I know it did for me. Because changes are immediately reflect you can much more easily experiment with small changes and see them immediately while you're editing them. This is especially useful for CSS changes that often are very fiddly, but also for script HTML layout changes.
Either way it's a great productivity enhancing tool.