ClickOnce upgrade rollback limits: when does automatic rollback not occur?

Rollback behavior limits

ClickOnce provides an automatic rollback mechanism that restores the previous version when an update deployment fails before the new version is marked active. This behavior depends on the presence of an <update> element with an expiration attribute in the deployment manifest. However, the mechanism is not guaranteed in all failure scenarios.

When an update failure occurs after the new version has been activated but during file download, the runtime may leave the application in a partially updated state, and no automatic rollback is performed. Developers can invoke ApplicationDeployment.Rollback manually, but this API is only available for online ClickOnce applications, leaving offline‑installed instances without a programmatic recovery path.

Given these constraints, it is unclear how to reliably detect and recover from a partially applied update, and whether additional configuration or logging can mitigate the risk of a corrupted installation.

Unresolved questions

• Under what precise conditions does ClickOnce skip automatic rollback after a failed upgrade?
• Is there a supported method to trigger a rollback for offline‑installed applications?
• What diagnostics can reliably indicate a partially updated state before the user launches the application?