Home > Articles > Repackaging Applications for Distribution

 Repackaging Applications For Distribution

Repackaging refers to the recreation of an application’s installation by capturing the differences in a computer before and after the application is installed. These changes are then combined into an installation “package” which may then be applied to another computer to enforce those same changes- resulting in an installation of the application. The single reason for creating such an installation package is to automate the installation so that the graphical interactive installation process may be avoided. A repackage installation can be used to effectively install the application with the same results on every computer and with no interaction necessary. Many organizations have a deployment mechanism in place that will allow them to remotely execute this package on machines without having to touch each computer. This is obviously a more desirable method of installing an application when compared to visiting hundreds or thousands of machines and going through an interactive installation process each time, entering the same information over and over again. Not only would this be time-consuming, but it also introduces room for human error in responding to the many questions presented during a typical software installation. Some applications support command-line switches or answer files that allow a silent customized installation, but not many. It is the very limited support for such unattended installations that makes the repackaging of applications a common task for many administrators responsible for large networks.

     Another reason for repackaging and application is to create Windows Installer compatible MSI files for applications. Windows installer packages allow several desirable features including automatic replacement of damaged or missing files. To use Windows 2000’s IntelliMirror features, applications must support the Windows Installer (MSI) standard. Only a small handful of applications come with native MSI files for their installation. Therefore it is often necessary to generate your own MSI installation packages using a repackaging tool. To repackage these applications with the goal of creating an MSI file you may use WinInstall (which comes with Windows 2000) or others available tools such as Wise for Windows Installer and InstallShield.

     * See http://www.appdeploy.com/tools/creation.asp for other repackaging tools. 
     * See http://www.appdeploy.com/faq/windowsinstaller.asp for more information on the Windows Installer.

     One of the primary problems with repackaging applications is inadvertently capturing unrelated, unnecessary or even damaging elements in the generated package. For instance, restarting a computer generates several changes to both the registry and even some files on the system. These are not necessarily required as part of the application being repackaged. Accidentally capturing hardware information or computer specific files and information may cause all kinds of problems when propagated to other machines on the network. Some experience is necessary in knowing what should be removed or excluded from the repackaged installation prior to deployment. See Repackaging Cleanup Tips for some help in this area. Every application will be different, but one good resource for dealing with the problem is PackageCleaner, for more on that tool click here.

     Any programs running during the time that differences are being captured may result in file modifications that are unrelated to the installation you are trying to capture. Disabling virus protection or other resident software on the system will reduce the likelihood of such files being included in your initial before/after snapshot. Removing these undesired changes is an option when using most every repackaging tool on the market. If you are stopping the changes from taking place during a repackaging session or removing those known elements after the initial package is created, it is important that only the files needed by the application are included in the final package to be distributed.

     Yet another concern when repackaging an installation is that any files that the installation would normally install will not be installed if already present on the system. This means that the installation package you end up with may not include every file needed by the application. For this reason it is a consistent recommendation by repackaging software vendors that the before and after snapshots be performed on a workstation containing no extra software of any kind. If you have a consistent baseline that you are installing to and they all contain the same applications, you could create the packages with those applications in place. However, it is likely that there will come a time when it is desired to install the package on a machine that contains some difference from the intended baseline. It is therefore best to repackage an application on a machine containing only the operating system and the latest deployed service pack. This will best ensure that all files needed are installed and captured in the repackaging process. Most repackaging software allows the setting to cause the package to overwrite only older files so that you do not inadvertently apply an older version of a shared file. This will help ensure you do not overwrite new DLLs with old ones.

     Finally, repackaged installations are stripped of the logic intended by the developers of the software. Simply applying files and registry entries captured in the repackaging process cannot account for checks for space, compatibility, previous installations, conflicting components, or a host of other variables of interest to the application. For this reason, repackaging is most successful when all target computers are of the same configuration and have the same software installed.

See PackageCleaner

Bob Kelly
November, 21 2000