Skip to content

Changes Cloudhouse Must Make

The changes below are held in the package root, not under ProgData. They are made by Cloudhouse and reissued to you. This is not a support policy: the configuration files in the package root are covered by the package's licensing hash, so editing one invalidates the licensing tokens, and the Compatibility Package stops deploying or running until it is re-licensed. Only Cloudhouse can re-license a package.

Typically, a change made by Cloudhouse requires the Compatibility Package to be redeployed. We deliver it by rebuilding and reissuing the base package, so no machine has the change until it is deployed again.

Note: When we make one of these changes, we update the base package and reissue it, then you redeploy. This way our changes persist across redeployment, and it is the same discipline asked of you in Updating a File Inside the Package: the change is only permanent once it is in the base package.

Change Why it needs us
A new version of the application, or a vendor patch or hotfix A new version means new files and newly captured settings. The Compatibility Package is rebuilt from the new installation media.
How the application behaves inside the container These are settings in the Compatibility Package's own configuration files, in the package root, which the licensing hash covers.
Where the application looks for its files and settings These rules live in Redirections.xml, in the package root. It cannot be edited in place, so the change is made in the base package and the Compatibility Package reissued.
Registry settings captured into the Compatibility Package The Compatibility Package carries its own copy of the application's registry settings, in AppRegistry.xml in the package root. A change made on the machine outside the container may be ignored, or may be replaced the next time the Compatibility Package is deployed.
Windows services, and the conditions under which they start Service definitions and their start conditions live in Services.xml and Programs.xml, in the package root.
File associations, right-click menu entries, and shortcut targets These are registered by the Compatibility Package when it deploys, and are reapplied on each deployment.
Drivers the application depends on Drivers are not virtualised, so they are never inside the container. They have to be installed on the machine and be compatible with it.
Turning on diagnostic logging Logging is switched on by a change to the package configuration in the package root. If diagnostic logging is needed, we will arrange it with you on a call and reissue the Compatibility Package.

Related Pages