CODEWITHSUNDEEP
wixwindows-installerdisk
user2998079
user2998079

Reputation: 11

WiX installer taking up too much disk space. How can I avoid disk sprawl with my installers

I have been working on a group of installers over a few years and am starting to run into problems with the amount of disk space that is used when the package is installed. The installer works great but installs/copies a few redundant sets of files in the process. I do admit that that some of my assumptions may not be correct, but this is based on my best understanding of the MSI processes. Let me explain ...

1.) Self-extractor file - The compressed MSI, associated bootstrapper packages and setup.exe file is downloaded by the user creating the 1st set of redundant files. Not a big deal, because this can easily be deleted after install.

2.) Extracted Files folder - After running the EXE the files are extracted to a static location from which the bootstrapper is launched. This now has created the 2nd set of uncompressed redundant files on the hard drive. These files are useful to be able to re-install of debug installs as needed, but may not be needed after install is completed. It has never been clear to me whether patched installs depend on these files or only the files stored in C:\Windows\Installer. Assuming the latter.

3.) TEMP folder - As the installer runs from the extracted location it copies files to the TEMP folder and runs the files from that location. This creates the 3rd set of redundant files. Again it is not really clear whether these files can be removed after install or if there is an automated process that MSI does to make this happen.

4.) Windows\Installer folder - If I understand correctly this is where some sort of stripped out file set is stored that manages the ability to patch. So this is the 4th set of files that may or may not be smaller than the some of the extracted sets of files. This one needs to not be deleted so patching will work.

5.) Install folders - Final install location for the software. This is now the 5th set of files that are installed to my computer and of course is the desired set of files.

I would like to better understand the process so I can improve the way that I distribute our software so that I can avoid or resolve some of the issues I am seeing with needing many different sets of files. I am very open to any best practice that might be out there that I have not observed. Thanks for your help.

Upvotes: 1

Views: 764

Answers (1)

Rob Mensching
Rob Mensching

Reputation: 36006

I can't speak to the exact bootstrapper you are using but you might investigate using the Burn bootstrapper in WiX v3.8 to create a Bundle of Packages. I know the details of how that works and it will reduce the number of copies from what you are experiencing now.

  1. Self-extractor file - a Bundle this can either contain all the files in the single executable or download them from the internet on an as needed basis. In the latter case, the self-extractor file could be ~250K.

    Of course, this can be deleted as soon as the install is complete.

  2. Package Cache - the Burn engine carefully downloads files to the TEMP location, verifies their integrity and moves them into the well-known Package Cache without creating any other duplicates. The Package Cache is important because the Windows Installer can get into situations where it requires the original source files. If that location is in a TEMP location that was deleted the user will have a very hard time providing the original source files. The Package Cache also improves the reliability of the installs. Finally, it is a cache so it *can * be removed (although not recommended) and the next execution of the Bundle will put the necessary packages back in the cache.

    Also, this content is the original source media and can still be compressed.

  3. Windows\Installer folder - the Windows Installer will cache the .msi file. If you do not embed the cabinet files in the .msi file (which is unnecessary when using a Bundle since the Bundle can embed all the files if desired) then the cached .msi file should be less than a couple megabytes.

  4. Install Folders - this is your application, you probably need these files here. :)

So, in the end using the Burn engine you should end up with one copy uncompressed (the app itself), one copy compressed (the package cache), and a tiny bit of overhead for the .msi file cached.

Upvotes: 2

Related Questions