AutoReload in IIS

Hi guys

Im having trouble getting AutoReload to work with UDDashboard hosted in IIS.
I read trough the docs/github/forums and it seems it should be possible(?)

When i specify the parameter we get following line in the UD-logs:
[Error] AutoReloader Unable to connect to the remote server

We made no changes to the AppPool settings. We work with HTTPS.

Appreciate any help on this


Hi @gitbute thanks for posting your question…on one of the first dashboards I designed I needed to stop and start it for the dashboard to update…so I got the IIS tools for powershell and simply added a scheduled task to stop and start the site at like 04:00am every day…the site works flawlessly, I hope this is what you are asking?

Hi psDevUK

Thanks for the reply.
No, i meant the ‘hot-reload’ functionality (i think its provided by webpack if im not mistaken?),
that when you save a dashboard-file that it instantly updates the dashboard.
Im not sure how the AppPools in IIS are working internally so im not sure thats possible over IIS.

If not, i could make a script with a FileSystemWatcher wich restarts the AppPool if some file changes, but i thought i would ask here first for a nicer solution.


Hey, welcome to the forums.
Take a look at my post from a while ago.

I did exactly that (with the filewatchers) .
On my end though, I separated my files so I load all the pages from a pages folder and endpoints from a endpoints folders (Basically New-UDPage or New-UDEndpoint is returned for each file)

This allowed me in turn to use filewatchers that will either triggers the Update-Dashboard cmdlet, reloading the whole dashboard in a fast manner or restart IIS pool associated to my dashboard.

You don’t want to restart the app pool whenever possible but when working with endpoints, if you simply run Update-UDDashboard, then the pages are refreshed but changes in the endpoints are not detected, hence why I used a combination of both.

I now use that everyday in my scaffolding module (WIP) DudDashboard - thread here

Except I did go further and added a button directly in my debug pages who triggers the filewatcher.
Normally, that would be a problem as anything which is run would also die when the app pool process is restarted, except that with an additional trick — see this — you can actually persist the process by creating it not as a child process (default behavior) but as an independant process.

1 Like

Although you’d have to edit them a little bit so you use your values instead of my cached variables, I also use, as a secondary measure when I don’t want the automatic refresh or want to trigger it manually for some reasons, the following endpoints.

New-UDEndpoint -AuthorizationPolicy login -Url '/dud/Update' -Endpoint {
    $params = @{
        Url         = $Cache:dud.Settings.HotReload.UpdateURL
        FilePath    = "$($Cache:dud.Paths.root)\src\root.ps1"
        UpdateToken = $Cache:dud.Settings.UDConfig.updatetoken
    Update-UDDashboard @params
    return $true

New-UDEndpoint -Url '/dud/Restart' -Endpoint {
    try {
        Import-Module WebAdministration
        $ApppoolName = $Cache:dud.Settings.HotReload.Apppool
        Restart-WebAppPool -Name $ApppoolName -ErrorAction Stop
        return 'true'
    catch {
        return $_

That way, you can go to your dashboard URL /api/dud/restart or /api/dud/update to triggers the restart / update manually.

If you screw up something and the dashboard crashed, you will never get to the endpoint and will need to kill the w3wp process manually though…

1 Like

Hey, thanks for the input!
I did a script which now runs as a scheduled task an keeps running, like a service (didnt want to deal with creating a service out of it tho)
I had to work out some shenanigans with FileSystemWatcher because it has a weird bug wich makes it trigger the same event twice in some circumstances.
Then i created a ‘testing’ REST-Endpoint which tests my dashboard upon restart, because the AD-Authorization sometimes craps out upon restart and i can catch that and restart it again.