Skip to content

How the Server Location is Found

When the launcher starts, the very first thing it has to figure out is where the server copy of Pulse Dashboard lives. Without that, there's nothing to sync against. This page explains how that determination happens, and the role the ServerPath.txt file plays.

The short version

In normal operation, the launcher figures out the server location automatically from where the launcher itself was launched. ServerPath.txt is a fallback, not the primary mechanism. It exists to help the launcher recover when the normal auto-detection breaks down.

The full mechanism

When you double-click a shortcut, Windows starts the launcher executable. The launcher then asks the operating system: "Where am I running from?" That's Application.StartupPath in technical terms — the folder containing the .exe that's currently running.

In a healthy setup, that path is the network share where the master copy of Pulse Dashboard lives — for example, \\web-server3\ApplicationUpdates\PDS\. The launcher uses that as the sync source, finds the rest of the application files in the same folder, and proceeds normally.

This works for the overwhelming majority of launches. No config file is consulted, nothing is remembered, the launcher just figures it out from where it was started.

When auto-detection fails

The launcher's startup path can become unreliable in several real-world scenarios:

Mapped drive letters that resolve differently per machine

One user has \\fileserver\apps mapped to S:\. Another has it on T:\. A third hasn't mapped it at all. If a shortcut points to S:\PDS\Pulse Dashboard Client.exe, it works for the first user but breaks for the others because Windows can't resolve S: on their machines.

DFS namespace or path changes

The IT-facing path users see (\\company.local\apps\PulseDashboard\) might be a DFS namespace that points internally to a real server like \\fileserver-04.company.local\apps\PulseDashboard\. If the namespace breaks, the underlying server name changes, or DFS replication has trouble, Application.StartupPath may suddenly point somewhere unusable.

Stale or moved shortcuts

A user has an old shortcut on their desktop from when the server was at \\old-server\apps\. The shortcut still launches the launcher, but the launcher's startup folder is no longer where the rest of the application files actually live (because everything has since been moved to \\new-server\apps\).

Drive letter conflicts

A user's S: used to be the company share, but they've remapped it to their personal NAS. The shortcut still says S:\PDS\Pulse Dashboard Client.exe and the launcher starts up "from" the wrong place.

How ServerPath.txt helps

ServerPath.txt is a small text file the launcher saves in the local install folder:

C:\Users\<username>\AppData\Local\Leahy\Pulse Dashboard 5\ServerPath.txt

It contains a single line: the last known-good server path. When the launcher can't find the application at its startup path, it reads this file and uses that path as the sync source instead.

The file is created or updated in two situations:

  • The first time a user successfully runs the launcher and uses the browse dialog to pick the server location.
  • Whenever the user is prompted to browse and confirms a path — typically because both the startup path and the existing ServerPath.txt are no longer valid.

The full resolution flow

When the launcher starts, server-location resolution happens in this order:

flowchart TD
    Start([Launcher starts]) --> CheckStartup{Pulse Dashboard.exe<br/>found at launcher's<br/>startup path?}
    CheckStartup -->|Yes| UseStartup[Use startup path<br/>as sync source]
    CheckStartup -->|No| CheckSaved{ServerPath.txt<br/>exists?}
    CheckSaved -->|Yes| TrySaved{Pulse Dashboard.exe<br/>found at the saved path?}
    CheckSaved -->|No| Browse[Prompt user to browse]
    TrySaved -->|Yes| UseSaved[Use saved path<br/>as sync source]
    TrySaved -->|No| Browse
    Browse --> UserChoice{User picks<br/>a path?}
    UserChoice -->|Yes| SaveAndUse[Save to ServerPath.txt<br/>and use it]
    UserChoice -->|No| Exit([Exit])
    UseStartup --> Continue[Continue with sync]
    UseSaved --> Continue
    SaveAndUse --> Continue

To put it in plain language:

  1. The launcher first tries its own startup path. This is the fast, normal case. The shortcut works, the network mapping resolves, the .exe is right there next to its dependencies. Done.

  2. If that fails, it falls back to ServerPath.txt. This is the recovery path. The user previously ran the launcher successfully, so there's a known-good UNC path saved on disk. The launcher uses that even though its own startup path is currently broken.

  3. If that also fails, the launcher prompts the user to browse. This is the last resort — typically the first launch on a brand-new machine, or a machine where both the startup path and the previously-saved path have become invalid. Whatever the user picks gets saved to ServerPath.txt for next time.

How the launcher tells you which method was used

The log file records which resolution method was used in a single line near the top of every session:

[INFO ] Sync source (server): \\fileserver\apps\PulseDashboard\  [resolved from: launcher startup folder]

Three values are possible in the [resolved from: ...] annotation:

Annotation What it means
launcher startup folder Auto-detection worked. The shortcut's path was usable. (Normal case.)
ServerPath.txt Auto-detection failed. The launcher used the saved fallback path.
user-selected via browse dialog Both auto-methods failed. The user just picked a path.

If you see ServerPath.txt or user-selected via browse dialog in a user's log when you'd expect launcher startup folder, that's a signal that something is wrong with their network setup, drive mappings, or shortcut — not with the launcher itself.

Why this design

You could imagine a simpler version that always reads ServerPath.txt and ignores the startup path. The reason we don't:

  • It would force every install to maintain a config file by hand. New users couldn't just run the launcher; someone would first have to write ServerPath.txt for them.
  • It would split the source of truth. Right now, "where does the launcher sync from?" has a clear answer for normal use: "wherever you ran it from." Adding a config file as the primary mechanism makes that question ambiguous.
  • It would make moving the server harder. Right now, IT can move the share, publish a new shortcut, and users are immediately on the new path. Config files would each need to be updated.

The current design is the best of both worlds: zero config in the normal case, with a graceful recovery mechanism for the cases where the network disagrees with itself.