Hardcoded paths in the package are one of the most common hidden causes of unstable application behaviour. They look harmless during packaging, especially when everything works perfectly on the engineer’s own machine.
The real issues appear later, when the package runs on devices where the system drive is not C:.
Some organizations use D:, E: or custom drive mappings, and any script or installer that assumes C: immediately becomes unreliable.
What can go wrong
Hardcoded paths create a wide range of unpredictable issues. The most common ones are:
- Wrong installation directory
The script forces installation to C:, although the system drive on the target machine is different. - Post-install configuration never applies
PSADT logic looks for files or folders on C:, while the actual installation is located elsewhere. - Broken shortcuts
A shortcut is created with an absolute path on C:, but the application is installed on another drive, so the user cannot launch it. - Detection logic does not work correctly
If detection checks rely on absolute paths, they may not recognise the application when it installs to a different drive. - Incorrect handling of user directory
Some applications place user-specific data inside AppData or profile-based folders. If the path is hardcoded, this configuration may apply only to the user account that was present during packaging, instead of the actual user who receives the application. The installation looks successful, but the required settings never reach the right profile. - Upgrade or uninstall paths break
A previous version may live on D:, while the new version expects C:. As a result, the upgrade does not trigger correctly and both versions remain installed on the system, creating inconsistent behaviour.
How we prevent this at Apptimized
To avoid these issues, we rely on dynamic path handling in every package.
In PSADT we use built-in variables instead of absolute references.
All available variables are defined in the AppDeployToolkitMain.ps1 file, where the global variables are listed and documented. Examples include $envProgramFiles, $envCommonDesktop, $envSystemRoot and many others.
They automatically resolve to the correct system locations and do not rely on a specific drive letter.
In MSI packaging we use the Directory table as intended.
Instead of writing absolute paths, we reference standard MSI directory identifiers, which resolve dynamically on each device.
For shortcuts we also avoid fixed paths.
If a shortcut needs to point to the installed application, we define its target using either MSI directory entries or PSADT variables.
This prevents broken shortcuts and keeps the behaviour consistent across all devices.
All post-installation actions, such as copying files or modifying configuration settings, follow the same approach.
We always refer to directories through variables to ensure that every operation adapts to the actual environment.
Why avoiding hardcoded paths is essential
Hardcoded paths may look like a minor detail, but they create behaviour that varies across devices.
In environments where machines differ in structure or drive layout, this leads to results that are unpredictable and difficult to control.
A reliable package should adapt to the system automatically.
Using dynamic paths ensures clean, consistent and stable behaviour, no matter where the application is installed.
If you need assistance with building stable packages and want to avoid similar pitfalls in your environment, feel free to contact us. We are always happy to help.
