INFO: Disadvantages of Repackaging Applications

This article describes the disadvantages and technical difficulties of repackaging applications for use with the Windows Installer setup engine.

Capture or "discover" utilities are designed to convert legacy installations into the new Windows Installer format; an MSI package.

These capture utilities, such as Veritas WinInstall LE which ships on the Windows 2000 Server CD-ROM, take a picture of a system before and after installation. Any registry changes, files changes, or systems settings that occur during the capture process will be included in the installation.

Installation Background

Windows Installer is designed to be more integrated in the application development cycle so that system administrators can have greater flexibility when they roll out applications in their corporate environment. To accomplish this, the application's developers considered redistribution during early development phases, as opposed to the final development cycle.

By waiting until the final development phase to create a setup package, the application had no support for its own installation; it relied on a completely unrelated technology to be installed. As a result, total cost of ownership (TCO) was greatly increased because system administrators had come up with their own unique method for redistribution. Sometimes these solutions were a large contributor to the "DLL Hell" problem. Repackaging does not solve all these problems. It can sometimes compound the problems of legacy installation technologies and increases the complexity because of the added extra layer of implementation.

Windows Installer is the current and future method of installing applications in the Windows environment. It is a database-driven installation technology as opposed to being script-driven, and it offers several advantages, such as changes made to a system by the application setup can be rolled back during installation. To take full advantage of the Windows Installer features, the application developer should involve MSI in the development phase. For more information, see the white paper about Windows Installer on the following Microsoft Web site at:

Common Problems and Issues

• Resiliency

  Resiliency can be inconsistent with repackaged applications because the repackager utility may not fully understand the component dependencies or what the key paths of the application should be. Therefore, an application may be packaged into one large feature that gets entirely reinstalled if a component keypath is missing. If it were broken up into multiple smaller features it would enable a more manageable resiliency.

• COM/ActiveX Registration

  Component Object Model (COM) and ActiveX controls may not be properly registered. Prior to Windows Installer, COM and ActiveX registration was a black box. Except for the exported functions DLLRegisterServer and DLLUnregister server, COM and ActiveX controls offered very few hints of their registration process. RegSvr32.exe was responsible for calling the previously mentioned functions and then the DLL was responsible for registering itself. There is no utility that can view a DLL, an OCX, or an EXE and figure out what goes on inside DllRegisterServer and DllUnregisterServer for that file. There are standard registry entries that most COM and ActiveX controls register, such as HKCR\CLSID, HKCR\ProgID, and HKCR\TypeLib. Information on COM registration may or may not get entered into the appropriate MSI tables by the repackager.

• Shortcuts

  Shortcuts may not be created as Windows Installer descriptor shortcuts, which enable resiliency. Legacy setup shortcuts were .lnk files that pointed to an executable in most cases. Sometimes when the repackager runs, all it knows is that an .lnk file was copied to a directory. For example, a legacy Setup.exe installed a shortcut to C:\Windows\Profiles\User1\Desktop. The repackager would copy the .lnk file directly to the directory listed previously. Therefore, the repackager is not actually copying a Windows Installer shortcut, but rather it is copying a file without any resiliency capabilities included.

• Isolated Components

  The only way to take advantage of isolated components is to author a new MSI package. Repackagers currently do not support this feature.

• Application Removal

  When uninstalling a repackaged application, it is possible that the AllUsers profile may be removed. This is dependent on how the legacy setup was captured and definitely needs to be tested.

• Group Policy and Advertisement

  Receiving the following error message is a common problem when assigning to GPO:
  The size of the object exceeds the limit set by the administrator.
  This is especially true when trying to repackage an application as large as Microsoft Visual Studio 6. The error message is misleading in the sense that it conveys to the user that there is some ADSI setting that can be made to alleviate the situation. There is currently no workaround for this error message. This is a repackaging issue because of the superfluous information this process sometimes places in the MSI package. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
  262166  (http://support.microsoft.com/kb/262166/EN-US/ ) Publishing Applications in Active Directory May Cause Error

• Directory Structure

  Directory structure chaos is a common problem when repackaging because of all the differences in the directories of the Win32 operating systems. Consider the operating system directory locations for each of the following environment variables:
  • 
    
  • System Directory
    Windows 95, 98, 98SE, and Millennium Edition = Windows\System.
    Windows NT and Windows 2000 = WinNT\System32.
  • Profile directory
    Windows 9x/ME = Windows\Profiles
    Windows NT = WinNT\Profiles
    Windows 2000 = Documents and Settings
  Therefore, if you capture Microsoft Windows NT and then try to install the MSI package on a Win9x OS, any files that should have gone to the Windows\System could go to the WinNT\System32. Therefore, the application files do not get installed to the proper directory. A "best practice" for this scenario is to capture or repackage for each Windows platform so that the directory structure and operating system-dependent files are captured properly.

• ANSI vs. UNICODE

  Applications sometimes need ANSI- or UNICODE-specific libraries. ANSI libraries are typically found in Microsoft Windows 95 and Microsoft Windows 98. UNICODE was designed for Windows NT 4.0 and Microsoft Windows 2000. If you create an MSI package designed specifically for UNICODE or ANSI, you have problems when you start redistributing your packages across Windows 95, Windows 98, Windows NT, and Windows 2000. This is another good reason to repackage for each OS version.

• Customization (Repackaging vs. Transforms)

  If your application was originally built in the MSI format and you want to customize your package, you do not have to use repackaging. Windows Installer is designed with system administrators in mind and has anticipated the need to customize packages. The Windows Installer supports a feature called Transforms (.MST) that is designed for customizing installs.
  
  For more information, see the Transforms topic in the Windows Installer SDK on the following MSDN Web site at:
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/transforms.asp (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/transforms.asp)
  For additional information, see the Custom Installation Wizard in the Office 2000 ORK on the following Microsoft Web site at:
  http://office.microsoft.com/en-us/FX011511491033.aspx (http://office.microsoft.com/en-us/FX011511491033.aspx)

• User Account Configurations

  When you repackage an application, any changes that are made under a user account may be what is installed. For example, the legacy application, MyProgram.exe, has been converted to an MSI package under the local machine account Administrator. MyProgram.exe has a shortcut on the desktop (C:\Documents and Settings\Administrator\Desktop\MyProgram.LNK) and stores user settings in the USERPROFILE (C:\Documents and Settings\Administrator) subdirectories. User1 logs in and runs the MSI. User1 receives an error message because he or she does not have permissions to write to the Administrator folder. Even if User1 has admin privileges or runs the MSI with elevated privileges, the MSI is going to write the desktop shortcut into the Administrator profile. The same thing applies to user settings and user specific data; it is all going to run from the C:\Documents and Settings\Administrator directory. Therefore, when you repackage an application, an exact copy of the differences may be written to the profile of the user who installs the MSI package.

Suggestions

If you decide to use the repackaging tools, you need to remember a few things:

• Always use the tool on a totally clean computer; make sure the computer has no other applications installed.
• Close any non-essential services.
• Create a package for each hardware configuration you have. For example, if you have 50 Dell XYZ computers and 50 Gateway ABC computers, you need to make packages for each type of system because of all the different hardware and drivers loaded on each computer. You want to keep each package limited to your specific hardware and software configuration.
  
  For additional information about getting through this process, click the article number below to view the article in the Microsoft Knowledge Base:
  257718  (http://support.microsoft.com/kb/257718/EN-US/ ) How to Create Third-Party Microsoft Installer Package (MSI)

For additional information about publishing legacy applications on a Windows 2000 domain, click the article number below to view the article in the Microsoft Knowledge Base: