Skip to content

Managing Changes to a Live Compatibility Package

This page sets out the changes that can be made to a Cloudhouse Alchemy Compatibility Package once it is in service, who makes each of them, and how they are carried out.

Some changes you can make yourself. Some must come to Cloudhouse. This page summarises both, along with the two rules that apply to all of them. The pages linked below cover each area in full, including the steps and commands.

Typical reasons you may want to update your Compatibility Package include:

  • A change to an application configuration file, for example a server name, a data path, a licence server or a logging level.
  • An executable, library or other application file inside the Compatibility Package needing to be updated or replaced.
  • An additional file, plug-in or template the application needs in order to do something new.
  • A change to the environment the application runs in: a new database server, a renamed file share, a replaced certificate.

The guidance applies to both desktop Compatibility Packages and packaged server applications. Where it applies to only one of those, the page says so.

The Two Rules

Only ProgData can be changed. The Compatibility Package has two parts. ProgData holds the application's own files, and is the part you can change. The package root holds the .xml and .clc configuration files and the Cloudhouse programs. The root is ours: the configuration files in it are covered by the package's licensing hash, so changing one invalidates the licensing tokens and the Compatibility Package stops deploying or running until it is re-licensed. Only Cloudhouse can re-license it, so root changes come from us — sometimes as an update you run against your own package folder. See Package Structure and Locations.

A change only lasts if it is in the base package. The base package is the master, undeployed copy you deploy from. A change made only in the deployed copy on a machine applies to that one machine, is lost when that machine is redeployed, updated or rolled back, and no other machine ever receives it.

Note: The most useful thing you can do for supportability is to keep the base package matching what you actually run. When the two have drifted apart, every later investigation starts by working out how, and the next version is rebuilt from a copy that is missing your changes.

Who Makes Which Change

Changes you can make Changes Cloudhouse must make
Application settings and preferences A new version of the application, or a vendor patch or hotfix
Configuration files the application reads when it starts How the application behaves inside the container
Licence keys, licence server names and port numbers Where the application looks for its files and settings (Redirections.xml)
User data, documents and user profile content Registry settings captured into the Compatibility Package (AppRegistry.xml)
Application files under ProgData: a configuration file, an executable, a library, a plug-in or a template Windows services, and the conditions under which they start (Services.xml, Programs.xml)
Database connection details and service account passwords, on packaged server applications File associations, right-click menu entries, and shortcut targets
Scheduled task timings, web site bindings and certificates, firewall rules Drivers the application depends on, and turning on diagnostic logging

You do not need to tell us about the changes on the left, although it is always helpful if you keep your own record of what changed and when. For the changes on the right, raise a request with Cloudhouse Support: we rebuild and reissue the base package, and you then redeploy.

For the full detail, including where each change is made and what to be aware of, see Changes You Can Make and Changes Cloudhouse Must Make.

Does the Change Need a Redeployment?

Whether a change needs the Compatibility Package redeploying depends on where it lands.

Where the change is made Redeployment needed?
Inside the application, through its own settings screens No
A configuration file edited in its live location on the machine or server No. Close and restart the application. Also make the change in the base package if the Compatibility Package carries a copy of that file
A file updated under ProgData in the base package No rebuild by us. Machines already deployed receive it when they are next redeployed or updated
A brand new file or folder under ProgData that needs Redirections.xml updating Yes, and the Redirections.xml change is ours to make. Tell us before you add it
Anything in the package root Yes. We rebuild and reissue the Compatibility Package, and you redeploy

If Something Goes Wrong

  • To undo a change, or to go back to the previous version of a Compatibility Package, see Rolling Back a Change. If nothing you know of changed, raise it with us before rolling anything back: a rollback can destroy the evidence needed to find the cause.
  • To have an issue diagnosed straight away, send the detail listed in What to Send Us When You Raise an Issue.
  • If you are not sure whether a change is yours or ours, ask before you make it. Confirming it first takes far less time than putting it right afterwards.

In This Section