Simplest solution to replace a tiny file inside an MSI?

Question

Many of our customers have access to InstallShield, WISE or AdminStudio. These aren't a problem. I'm hoping there is some way I can provide our smaller customers without access to commercial repackaging tools a freely available set of tools and steps to do the file replacement themselves.

Only need to replace a single configuration file inside a compressed MSI, the target user can be assumed to already have Orca installed, know how to use this to customize the Property table (to embed license details for GPO deployment) and have generated an MST file.

Disclaimer: this is very similar to another question but both questions and answers in that thread are not clear.

Answer 1

You need to add an entry to the Media table, adding another medium with no cabinet file, and a LastSequence one more than the CAB file's last sequence. You then need to replace in the File table the file's sequence with the new file, and update all the other file attributes that may have changed.

Answer 2

I asume that you create the msi file yourself (?)

When you use Wix to generate your msi, the customer can simply regenerate the whole msi after replacing the file (wix is free). Otherwise it should be possible to use an uncompressed file which is not embedded in the msi. In wix you have to add a media element without a cabinet attribute. The disadvantage is that you have to distribute two files, instead of a single msi.

Answer 3

Okay, revisiting this question with my own answer providing nice little VB script that will do all heavy lifting. As mentioned in the original question, the aim was provide a simple solution for sysadmin users to make the updates/changes themselves.

Below is a simplified version of the code I'm currently providing to customers (the full version I'm using generates an MST rather than altering the MSI)

Const MSI_SOURCE = "application.msi"
Const FILE_REPLACE = "config.xml"

Dim filesys, installer, database, view
Dim objFile, size, result, objCab

Set filesys=CreateObject("Scripting.FileSystemObject")
Set installer = CreateObject("WindowsInstaller.Installer")
Set database = installer.OpenDatabase (MSI_SOURCE, 1)

Set objFile = filesys.GetFile(FILE_REPLACE)
size = objFile.Size

Set objCab = CreateObject("MakeCab.MakeCab.1")
objCab.CreateCab "config.cab", False, False, False
objCab.AddFile FILE_REPLACE, filesys.GetFileName(FILE_REPLACE)
objCab.CloseCab

Set view = database.OpenView ("SELECT LastSequence FROM Media WHERE DiskId = 1")
view.Execute

Set result = view.Fetch
seq = result.StringData(1) + 1 ' Sequence for new configuration file

Set view = database.OpenView ("INSERT INTO Media (DiskId, LastSequence, Cabinet) VALUES ('2', '" & seq & "', 'config.cab')")
view.Execute

Set view = database.OpenView ("UPDATE File SET FileSize = " & size & ", Sequence = " & seq & " WHERE File = '" & LCase(FILE_REPLACE) & "'")
view.Execute

Answer 4

IMHO this kind of scenario indicates a missing feature in the application being installed, and is easier to fix in the application than hacking around with the MSI.

---

Admin Image

Let me first say that a simple way to "solve" this for your users, is to tell them to run an Admin Installation of your MSI. This will essentially extract all the files from the internal CABs and put all files in the specified folder:

msiexec.exe /a myinstaller.msi TARGETDIR=C:\AdminImage

Your users can then go directly into the extracted folder structure and update the file in question and then map the directory to other PC's and install the MSI. There could be side effects to this relating to the file having a hash value in the MSI (to avoid spoofing), but in most cases it works fine.

---

Run XML XPath Query

New versions of deployment tools such as Installshield and Wix feature built-in support for running XPath queries during the installation and hence write sections dynamically.

---

Application Update

Setting up an application on a PC involves several steps. First there is the deployment of content to the machine - this should be done using an MSI, no question about it. However, in most advanced applications several "post installation configuration tasks" similar to this "config file update" are required.

It is almost always better to defer these configuration tasks until the application launch, rather than to implement features in the MSI. There are many reasons for this, but the most important being that only the application EXE will be guaranteed to run in the correct user context. MSI files can be run with system rights, a different user account or via some other mechanism.

What we generally recommend is to use the MSI to get all required content onto the PC. Then tag the registry to indicate to the application that it's the first launch (for updates, you can increment a counter or write the new version number to HKLM). Then the application can perform the final configuration steps in its startup routine. It can copy a default config.xml file from somewhere in %ProgramFiles% and copy it to the user profile. Then it can read required values from HKLM written by the MSI, and then update the config.xml file with these values.

In general: avoid configuration steps performed by MSI or any other setup mechanism. Concentrate on writing the required files and registry items to the machine, and then let the application itself set up a proper runtime environment. This will allow much better deployment control. It is better "Encapsulation" if you like. The MSI sends a "message" to the application via the registry, and the application knows "how to set itself up correctly" based on the messages.

Answer 5

Hi Sascha, not sure how to comment your answer so I'll ask my follow up here:

You don't seem to instantiate your objCab before you use it. Is there a bit of you sample code missing? I'd love to see the whole piece.

Many thanks. EC