Skip to content

Changes You Can Make

These are changes the application is designed to accept, and that do not require the Cloudhouse Alchemy Compatibility Package to be rebuilt. You do not need to tell us about them, although it is always helpful if you keep your own record of what changed and when.

Whether a change needs the Compatibility Package redeploying depends on where it lands. Settings changed inside the application and configuration files edited in their live location take effect on that machine straight away. A file updated under ProgData is a change to the base package, so it needs no rebuild by us, but machines already deployed receive it only when they are next redeployed or updated.

A redeployment is only needed where the change cannot be made in place: a new file or folder under ProgData that requires Redirections.xml to be updated, or any change to the package root, such as AppRegistry.xml, Services.xml or Programs.xml. See Changes Cloudhouse Must Make.

Changes to All Compatibility Packages

What you can change Where the change is made What to be aware of Update the base package too?
Application settings and preferences Inside the application, through its own options, settings or preferences screens. None. This is normal use of the application. No
Configuration files the application reads when it starts The configuration file in its live location on the machine or server. Close and restart the application for the change to take effect. Keep a copy of the file before you change it, so you can put it back. Yes, if the Compatibility Package carries a copy of that file. Otherwise the change is lost on redeployment
Licence keys, licence server names and port numbers Wherever the application normally holds them: its licence dialog, a licence file, or a configuration file. The licence server must be reachable from the machine. Changing a licence server is yours; changing the licensing product or mechanism usually needs a repackage. Yes, if the licence detail is held inside the Compatibility Package
User data, documents and user profile content The normal locations: the user's profile, a file share, a database. No additional considerations. No
Values the application reads at start-up, such as a server name or the path to a data share The setting or environment value in its live location. The application must read the value when it starts, rather than having it captured into the Compatibility Package. If you are not sure which applies, ask us. Yes, if the value is held inside the Compatibility Package
Data and log file locations the application exposes as a setting The application's own settings. The new location must be reachable, and writable by the account the application runs as. No
Application files inside the Compatibility Package: a configuration file, an executable, a library, a plug-in or a template Under ProgData, in the base package. Take a copy of the file before changing it. Yes. This is the change — see Updating a File Inside the Package

Note: Where the table says a file inside the Compatibility Package needs updating, that means editing or replacing it under ProgData in the base package. Deployed machines pick the change up when they are next deployed or updated.

Changes to Packaged Server Applications

What you can change Where the change is made What to be aware of Update the base package too?
Database connection details: server name, instance, credentials The application's own configuration, in its live location. The database must be reachable from the server. If the connection details were captured into the Compatibility Package rather than read from a file at start-up, this becomes a change for us. Ask if you are not sure. Yes, if the connection details are held inside the Compatibility Package
Service account passwords The Windows Services console, or your normal account-management process. The account must keep the rights the service needs, such as Log on as a service. Changing the account itself, rather than its password, is worth raising with us first: the service may need access to paths inside the container, and a change that looks correct can leave it starting but not working. No
Timings and schedules for scheduled tasks you own Task Scheduler. Do not change the task's Action, which is the command it runs. That points into the container. Yes, if the task was created by the Compatibility Package
Web site bindings and certificates you manage Your normal web server administration. Bindings and certificates are usually yours. Handler mappings, application pool identity, and anything pointing at a path inside the Compatibility Package are ours. No
Firewall rules and network access for the application Your normal network administration. The Cloudhouse URLs listed under Website and Port Requirements must stay reachable, or deployment and launch can fail. No

Related Pages