On Wed, Mar 6, 2019 at 9:35 AM Jacek Caban jacek@codeweavers.com wrote:
... It's not strictly related to this topic, but I like the idea of msidb having. Using msidb instead of winemsibuilder in Gecko build scripts would be a welcomed change. It would make VS builds, that Austin uses for Valgrind, able to do proper MSI build too.
I had some comments the last time I tried to submit these patches, so I'll make some time to go over them and resubmit. If I recall correctly there wasn't anything particularly difficult, I just unexpectedly got busy with other things.
On Wed, Mar 6, 2019 at 9:37 AM Vincent Povirk vincent@codeweavers.com wrote:
... That's an interesting idea. My understanding was that CAB files used by an MSI had to be flat (no directories), and this would prevent us from using the same CAB file as an MSI media and a stand-alone archive for the shared install.
Nope, but MSI has absolutely no capability for "recursively" unpacking directories. You must enumerate absolutely every single individual file you want from the cabinet - no exceptions. I have scripts that I use to do this that take the complete contents of a structured cabinet file and automatically create all the appropriate "Feature" and "Component" entries for each file and directory in order to ensure that the installer recreates the structure of the cabinet file. I personally find this to be incredibly useful for distributing installers with a lot of structure in them.
We could also put the c:\windows\mono directory in a separate feature so we don't have to install those files, but they'd still use space in the prefix from copying the MSI.
I'm not 100% sure I understand what you're trying to achieve, but I assume that you're trying to avoid having duplicate information for the same thing and to keep extraneous downloads to a minimum. If you wish then you can always have optional Features that don't get installed, and if you place them in separate cabinet files (you can always have more than one) then you can even skip downloading them if you know that you won't need them.
If you have a code example of an msi that installs another msi, that could be useful if we decide to use Jacek's idea, or if I need to make a fake .NET 4 msi.
I'm not sure how you generate your installers, but I create the "idt" files that are used for populating the tables with msidb. To call another MSI I always use a CustomAction (see CustomAc.idt/CustomAction.png) where the target should be a quiet msiexec (yes, I know this looks crazy - but it is completely valid): msiexec /i "[SourceDir]Bonjour.msi" /qn You must also add the action to the InstallUISequence table (see InstallU.idt/InstallUISequence.png) and the sequence _must_ match ProgressDlg (or equivalent).
Best, Erich
