What happens to customizations if you reinstall or update XMetaL?

[scorho]

What happens to customizations if you reinstall or update XMetaL?

For example, we've customized templates and .ctm files, .css files, and several xsl and js files. If we ever reinstall or update, will we lose these customizations?

I assume we can restore changes made in the DITA_OT directory by restoring from a backup, but can we do the same with files in the Program Files directories?

Reply

[gcrews]

It’s probably best to have some deployment method, that’s what I have done for us. I have a script that updated everything. CSS files, dll update, custom print xml file,  print_local settings, js files,  macros, ctm files, templates, ct_config file, and all the toolkit changes and customizations. Reinstalling the same exact version is no problem for us. Going to a newer version though takes me about a week to fully check everything, make sure any files that are customized don’t have new changes, ect… The longest part is merging the toolkit.

There are lots of customized code and xls that I have created for our needs. I try my hardest to keep my changes in plugins but sometimes you have to make changes directly. Also sometimes to make a small change to a xsl template, you have to usably copy the entire template to the plugin,  sometimes 100’s of lines of code just to  make a small change. When the toolkit gets updated eventually I’m going to either have to start from scratch or check every custom line of code I have create in plugins and compare the templates I have copied.

Reply

[Derek Read]

Hard to give a better answer than gcrews but I can add some details.

This applies equally to XMetaL Author Enterprise and Essential.

XMetaL Author Installers (and Uninstallers):
Our uninstallers are designed to check to see if any files or folders have been modified after installation and if they have been they should be left behind. Any files we install (pretty much anything in C:Program Files) are considered to be “owned” by XMetaL. The uninstaller may leave them behind if it detects that they were modified (via the file modification date stamp) but an installer may, and probably will, overwrite them if it considers them to belong to it. This would be the case if you uninstall and then reinstall the same version. The uninstall may leave files behind but the reinstall will (should) overwrite any files it wants to install. Note the distinction between installer and uninstaller here.

Our installers generally place new versions of the product in a different folder (by default) from the previous version so if you are installing a new version the installer probably won't overwrite your files because it is installing to a new folder.

Example:
1. Install 5.0. By default the product is installed to C:Program FilesXMetaL 5
2. Make changes to our installation.
3. Uninstall 5.0, some folders and files may be left behind.
4. Install 6.0. By default the product is install to C:Program FilesXMetaL 6
5. If you wish to migrate modified files from 5.0 to 6.0 you may wish to do so but our installer does not make any attempt to do this.
6. (Optional) Manually delete any folders and files left over from the 5.0 install. Note: Strategies for making sure our uninstaller cleanly uninstalls are listed below.

We may have chosen to change any files inside C:Program Files with each of our releases. There is also no guarantee that any particular file will still exist with a subsequent version. If you modify anything it is up to you to check to see if your changes are still compatible with whatever the default installation is with the new release. Depending on how many users you have and how important stability is to your company you will want to do more testing before you let your user-base use your modifications with any new release.

In general I think the best strategy is (to refrase what gcrews has already said):
– Keep track of any files you have modified.
– Store modified files elsewhere (backup) for safety. If you have multiple users you will want everyone (probably) using the same setup anyway, so storing them in a place everyone can get them from makes sense.
– Optionally (but highly recommended) create some type of installer. This might be a simple batch file that copies files from a network share, it might take the form of a zip file that you unpack after installing the product, or it might be a “real” installer that you run after installing the product (a lot of our larger clients do this). The main benefit to the last one is that (if you use something like InstallShield or similar) you should be able to cleanly uninstall your files and then cleanly uninstall the base version of XMetaL you installed. It also makes installation easier for the end user. However, it requires actual development and perhaps more testing. The same could be done with a batch file, provided the batch file doesn't just overwrite files, but uses some kind of strategy that will allow the original installation to be restored before running our uninstaller.
– With each new release make sure your changes are still compatible and do what they did with the last release.

Batch File Post-Installer / Pre-Uninstaller Examples:

After you perform a standard installation you might run a batch file similar to this:

[code=XMetaL Author Post-Install.bat]
REM Replace standard install files:
rename “C:Program FilesXMetaL 6.0AuthorDITAXACstopictopic_ditabase-specialized.css” topic_ditabase-specialized.css.original
xcopy  “X:networksharexmetal6.0modstopic_ditabase-specialized.css” “C:Program FilesXMetaL 6.0AuthorDITAXACstopic”

REM Add New Folders or Files (files that don't already exist in the XMetaL installation):
md “C:Program FilesXMetaL 6.0AuthorTemplateNew Folder”
xcopy  “X:networksharexmetal6.0modsTemplates” “C:Program FilesXMetaL 6.0AuthorTemplateNew Folder”
[/code]

Then, in order to allow the XMetaL Author uninstaller to properly remove everything you would need to restore the installation to what it was before running your “post installer” batch file. Something like this:

[code=XMetaL Author Pre-Uninstall.bat]
REM Restore standard install files:
del  “X:networksharexmetal6.0modstopic_ditabase-specialized.css” “C:Program FilesXMetaL 6.0AuthorDITAXACstopic”
rename “C:Program FilesXMetaL 6.0AuthorDITAXACstopictopic_ditabase-specialized.css.original” topic_ditabase-specialized.css

REM Remove Added Folders or Files (files that don't already exist in the standard XMetaL installation):
rd /s /q “C:Program FilesXMetaL 6.0AuthorTemplateNew Folder”
[/code]

Windows Vista and 7 Security:
Note that on newer versions of Windows the operating system secures the Program Files folders more tightly than previous versions of Windows (XP). A “real” installer can be created to run with “elevated privileges”. If you attempt to make modifications to C:Program Files manually without the correct priveledges you will likely be blocked, and the same is usually true for .bat files. This is an area that you will need to get your IT department to help with as they will know which priviledges you (or your end users) have, who must run installers, which portions of your system may be modified, etc.

DITA OT Modifications:
If you are working with DITA and have made changes to the DITA OT you may wish to see this:
http://forums.xmetal.com/index.php/topic,1008.0.html
There is also an older post here: http://forums.xmetal.com/index.php/topic,224.msg687.html#msg687

DITA Authoring Modifications:
We are planning a “37 Minute Webinar” that should cover supported changes to the DITA authoring functionality. An announcement for that should turn up here: http://forums.xmetal.com/index.php/board,9.0.html

Reply

[gcrews]

2 notes about the code segments:

I avoid using drive maped letters like x: in scripts. I alwas use the absolute UNC paths incase someone does have the drive letter mapped.

Also I try to never use absolute local paths like c: I always use environmental variables. Also to make it future 64bit compatible you might want some code like below and then use the progFiles variable.

[code]SET progFiles=%ProgramFiles(x86)%
IF “%progFiles%”==”” SET progFiles=%ProgramFiles%[/code]

Reply

[Derek Read]

Good points about proper use of environment variables.

You might also wish to look into using Power Shell (though it is not installed on all machines by default):
http://technet.microsoft.com/en-us/library/bb978526.aspx

Reply

[Author]

Posts