Blog Posts tagged with Repackaging

Ask a question

Repackaging Best Practices

This video training session discusses several best practices pertaining to repackaging. Discussions include establishing a clean machine, the need to reboot and launch an application when repackaging, eliminating unnecessary user information from packages- and how to handle such information if you find it necessary to include. It also covers cleaning your package, which applications not to repackage (and why). These and other best practices are discussed in detail with plans to expand the video based on future best practices and your own feedback.



Running Time: 21:45



This video covers Items that should not be repackaged, explaining the logic behind why these items should not be repackaged.


It also goes on to discuss other practices such as the removal of HKCU elements from your package to avoid the potential repair/reinstallation of MSI packages (some times repetitively).

View comments (3)

To Repackage or Not to Repackage

This video presentation is a higher quality redelivery of the Webinar offered online in October of 2007. It covers the pros and cons of repackaging versus making use of any automation support offered by vendor provided legacy setups.





Running Time: 37:12



Analyzing what is provided natively is the first step and, as a very important step, this is discussed in depth.


Demonstrating the process, Adobe Acrobat is downloaded, analyzed, and its deployment tested.

View comments (1)

Avoid Unnecessary Reinstallation of Repackaged MSI Setups

When a Windows Installer setup is authored, it may be broken up into features. When self-healing or install-on-demand actions take place, they do so at the feature level. Keep in mind that when you repackage an application it is typically bundled into a single feature. This means that any missing key component (a file or registry entry set to trigger the install/repair-on-demand feature of the Windows Installer when found missing) will mean a complete reinstallation of your package. For this reason it is a good idea NOT to include HKCU keys in your package when they are not needed (they are rarely required- a well authored application should generate defaults if they do not exist) as these will be missing for each user who first runs the application- meaning everyone who uses the application will have to wait for a full installation to occur.

Be the first to comment

How do I correct the error: File with key ??? located at ??? could not be compressed?

This may error may occur when trying to compile an MSI where a file that does not exist as source is included in the package. This is normally due to the accidental inclusion of a temporary file during the repackage process. View the "File" table within your package editor (database view) and click the "File Size" column to sort the files in your package by file size. Any files with a size of zero, must either be saved off during the installation process for later inclusion in your package, or (more often) they may be safely removed from your package. Temporary files created during the installation process which are then removed upon completion are normally the cause of such a problem.

Other errors that may surface as a result of a zero byte file in your package include 1612 - source not found (the msi file is not were it is expected) and 1625 - path to sourcefile wrong.

One visitor adds, "Most of the time, opening the package with Wise, converting it to a wsi (wise project) and compiling it again solves this issue"

Depending upon the tool you are using to manipulate your MSI setup packages, it is normally best to remove any files using the GUI view or your editor and not to delete directly from the FILE table- this is due to potential references to these files elsewhere in the MSI database that may not be taken to account when editing the table directly.

Be the first to comment

Why should I never repackage an MSI?

First of all MSI installations are already in a in a distributable format, so there is no benefit to recreating the setup. MSI packages are full of internal references, which cannot be captured and recreated. These internal references are critical to the self-healing functionality of MSI packages and are fundamental to their operation.

Repackaging an MSI may result in uninstall problems and other Windows Installer related problems. Finally, and perhaps most important, when the vendor releases and update or patch (MSP) for the product, it will be designed to update their MSI and not yours. When repackaging, all of the globally unique identifiers (GUIDs) used to identify items in the package are regenerated and will not match up to the updates provided by the software vendor package.

There are no changes that cannot be implemented at install-time using an MST (transform) file. Aside from dictating installation preferences, you can add, delete or change any items you wish. I have had some people challenge the fact that the capabilities of MST negate the need to repackage an MSI. While the statement is certianly a fact- it can admittedly be a very difficult task to carry out when dealing with certian packages. Have you given up on MST and repackaged an MSI? Please rate the applications difficulty and provide comments in the software's Package Knowledge base entry. Fighting with a package right now? The Package Knowledge base may hold some answers for you. Also visit our package development message board.

View comments (2)
Showing 1 - 5 of 58 results

Top Contributors

Talk About Package Development