ClickOnce Deployment – Promoting the Same Tested Build from UAT to Production

The better direction is to avoid putting environment-specific values inside the signed ClickOnce artifacts and have the application resolve them at runtime, such as from an external configuration endpoint.

Kindly share how to implement the above step?

Hi @Nagarajan Dhanapal ,

For the runtime configuration part, the idea is that the UAT/Production URL should not be stored inside the ClickOnce manifest, app manifest, or any signed file that is part of the ClickOnce package.

Instead, the application should read the environment-specific value from an external source at startup. For example:

• A config file created by uDeploy on the target machine, such as C:\ProgramData\CompanyName\AppName\settings.json
• A registry key created by the deployment process
• An environment variable
• A fixed configuration service endpoint that returns the correct environment-specific service URL

For example, uDeploy can place a file like this on the target machine:

{
  "ServiceUrl": "https://uat-api.contoso.com"
}

Then in Production, uDeploy places the same file path but with the Production URL:

{
  "ServiceUrl": "https://prod-api.contoso.com"
}

The application can read this file when it starts:

var configPath = Path.Combine(
    Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData),
    "CompanyName",
    "AppName",
    "settings.json");

var json = File.ReadAllText(configPath);
var settings = JsonSerializer.Deserialize<AppSettings>(json);

var serviceUrl = settings.ServiceUrl;

With this approach, the ClickOnce published package remains the same between UAT and Production. Only the external configuration changes, so the signed ClickOnce artifacts are not modified.

For the “Specify an install URL” message, that is a separate ClickOnce publishing setting. The Installation Folder URL is still needed as the ClickOnce install/update location. It should not be treated as the application’s backend/service URL. So you can keep a valid install URL/path for ClickOnce publishing, keep Exclude deployment provider URL enabled, and move the actual UAT/Production application URL outside the signed package as described above.

Hope this helps clarify the supported direction. If you need any further help, please feel free to reach out.

Hi Danny Nguyen,

Thanks for your reply.

I initially published with keep Exclude deployment provider URL enabled the build using the installation URL pointing to Server1 (e.g., http://server1/appname). From there, I was able to successfully download and install the application by running setup.exe, and the application installed correctly.

Later, I moved the same published package to Server2 (e.g., http://server2/appname). I can still download setup.exe, the application files are being downloaded, and the installation successfully but files are being downloaded from server1. we need the files to be downloaded from server2 instead of server1.

Could you please help me understand the correct approach to move a ClickOnce deployment from one server to another without breaking the installation/update process?

We already using environment specific application URL (External URL) but we need a mechanism to configure installation URLs(UAT/SIT/PRD) for the same package.

Hi @Nagarajan Dhanapal ,

Thanks for the clarification.

Exclude deployment provider URL only removes the deploymentProvider from the ClickOnce deployment manifest. It does not necessarily remove the original install URL embedded in setup.exe.

Microsoft’s ClickOnce guidance explains that excluding deploymentProvider supports deploying from multiple network locations without changing or re-signing the manifests: Deploy ClickOnce apps without re-signing.

However, Microsoft also documents a related case where the ClickOnce package was copied from one server to another, but setup.exe still tried to download from the original server because the publish URL was embedded in setup.exe: Installation of a ClickOnce application failing with an error pointing to a wrong deployment URL.

So in your case, if the same setup.exe was generated with Server1 as the install URL, then moving it to Server2 can still make it download from Server1.

For this requirement, the practical options are:

• Use a stable/common install URL, such as a DNS alias, and point that alias to the correct environment/server.
• Use an environment-specific setup.exe or update the bootstrapper URL for each environment.
• Launch/install from the .application file on the target server instead of using a setup.exe generated with another server URL.

If the installation URL itself must be different for UAT/SIT/PRD, then that part cannot remain fully identical across environments when using the same setup.exe, because the bootstrapper URL is environment-specific.

Hope this helps clarify the supported direction. If you need any further help, please feel free to reach out.

Hi, just checking in. Do you have any update on this post?