0

Some context: I want to include a private copy of a Java Runtime in my installed product. The .msi file should be build on a integration pipeline (Jenkins CI Server, will use WiX via a maven plugin).

One option is to unpack the JRE (archive) into a temporary directory while building the installer and have heat dir harvest it. However this requires unpacking, scanning and re-packing of files.

So I would prefer if I can provide an already complete jre.cab file and make WiX use it. Either by not having to specify the files, or by having heat harvest the cab content.

Is there a way to do this (other than unpacking the cab manually which I do not want to do as it then will not be recognized by the installer).

It would be even better if I can provide a ZIP or TGZ file instead of the CAB, but thats not a must. Creating a cab every time the JRE changes is fine.

eckes
  • 10,103
  • 1
  • 59
  • 71

1 Answers1

1

There are many good possible answers here. I'll give you two.

1) What I personally would do: (Skip Heat and encapsulate as Merge Module)

Create a build that extracts the cab and builds WiX Author an IsWix Merge Module project that includes all of the extracted files. Checkin and build when needed. Now you have an .MSM sitting on the shelf in your build archives area.

2) What I suspect you'll like better (Use Heat and encapsulate as Binary Wix Library)

Create a build the extracts the cab, runs heat and builds WiX Checkin and build when needed. You have a .wixlib/.wixobj sitting on the shelf in your build archives area.

I have tooling (IsWiX) that makes #1 a piece of cake. Yes you need to manually update the MSM WXS definition each time you accept a new CAB but I think that is trivial and important to do. It's more reliable. The MSM will slightly slow down your MSI creation as the compiler / linker has to unpack, repack the contents for you.

Option 2 assumes that Heat will never fail you. That scares me. It's a bit harder to create all the plumbing for up front and in theory less to maintain over time... assuming Heat will never fail you. (I wouldn't assume that.) The creation of your .MSI will be a little bit faster as the binary wixlib is in the optimal format for the compiler/linker.

Option 1 has the added benefit of being compatible with other tools such as InstallShield.

By separating the MSM and MSI creation into 2 builds you can choose when to build each and chain them together. This can be very valuable on massive projects. However in many situations the optimizations add unneeded complexity. If I was writing a small line of business app ( say 100MB total between app and JRE ) I probably wouldn't bother. I'd probably just run the whole thing as a monolithic build on a fast VM with SSD storage in a couple minutes.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Thanks it is less the time, its more the repeatet extraction and repacking which I would like to avoid. (So I want to avoid the manual step of creating the merge module). But I guess I can combine both as well? create a marge module using heat to fill in the details...? (I have no idea about WiX :). anyway, will accept your answer when it becomes eliglbe – eckes Oct 06 '15 at 11:33
  • 1
    The manual step for the merge module is updating it's manifest when the .CAB contents change. I don't think of this as some grueling step that should be automated, I think of it as analysis and development. IsWiX reduces the friction in doing that development. – Christopher Painter Oct 06 '15 at 12:14