Hi Rob, thanks for your answer The few shared files are in components defined manually, so it's not a problem. When it comes to the thousand of (unshared) files, manually defining components is not an option - there's no way to do it in code, one must use Installshield's clunky GUI. This setup works pretty well, except when it comes to patching. Indeed, NSIS's interaction with MSI is not that good, this is why we are looking for solutions of harmonizing patching with the main installer.
Regarding your personal philosophy, I don't think there's really a choice when using MSI. How am I supposed to know what files are to be modified on the user's system, in a future patch ? How can I correctly define components without an intimate knowledge of the relationship between files ? I can only go the paranoid path of one component / file, and at the same time, flush any performance down the drain - most of our files are small include headers in the KB range. Upon further consideration, maybe MSI is not that well suited for us, and what I should do is move the main product to an xcopy setup, and do away with these pesky components altogether :) -- Stelian ENE Installer Engineer, DevTech Freescale Semiconductor Romania Work: +40 21 305 2064 Mobile: +40 728 052 499 This e-mail, and any associated attachments have been classified as: [X] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary -----Original Message----- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 9:10 PM To: Ene Stelian-Bogdan; wix-users@lists.sourceforge.net Subject: RE: Integrate WiX in our process The "Dynamic linking" feature where Component Ids change with every build makes it impossible to patch. In fact, I think the only option available to you using that methodology for creating MSI packages is major upgrade. Also, I assume you don't have any shared files in the "big zip file" because those would not be reference counted correctly. It's interesting you use NSIS for the patches. Does the interaction between NSIS patches plus MSI repair/uninstall work out well? I'm not up on the intimate details of patching but there are new features in the WiX toolset that enable you to create patches that target subsets of your setup authoring. That enables you to build independent patches for different areas of your installation. However, when you need to patch the same file more than once, the patch ordering definitely becomes an issue. I'm not sure this advanced functionality is available unless you use the WiX toolset to create the MSI (I think a lot of information comes from the .wixpdb), but it *may* be possible using admin images. Ultimately, I believe that you are correct that maintaining Component Guids is going to be the hardest problem to tackle when creating your patch system. I know Bob had to tackle this exact problem in his day job so he may have suggestions of things to try or avoid. I also know that tallow/heat in their current form will not help you because they don't correctly assign Guids. I haven't tried paraffin but on my initial readings it looked like it was trying to do the right thing... but I don't know if it works in this sort of scenario. Note, these issues for Component Guid are a recognized pain point in the Windows Installer. I'm still working on a way to solve the problem of automatic Guid generation. Finally, the "philosophy" that each developer should maintain their portion of setup is my personal philosophy. The WiX toolset has features to enable such distributed setup development but that doesn't mean you have to use them. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ene Stelian-Bogdan Sent: Monday, May 19, 2008 09:41 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Integrate WiX in our process Hello, Here's the way our process currently looks like: - We build and ship the main product installer as an MSI, Installshield based project. I am talking about a 900MB product, comprising of about 15.000 files and 2300 folders, so we use Installshield's "Dynamic linking" feature extensively. (Basically, you point to a folder, and components will be generated on the fly at build time, one component per directory; the ComponentIDs will of course change on every rebuild) Needless to say, we don't subscribe to the MSI/WiX philosophy of having developers maintain the installer components; I receive one big zip file, and must deliver an installer. While I have nothing against changing this state of facts, I don't think it will change soon. - When new chips are introduced, we must deliver a "Service pack" that will offer compiling/debugging support for it. The patch will generally add new files to the installation, and sometimes update existing files, always in a backwards-compatible manner. Since customers will download only the patch offering support for the device they are working with, these patches can be applied more or less in any order. Currently, these patches are built using the NullSoft installer. As a first step, I'd like to get rid of NullSoft, and replace it with WiX; on the long run, a full transition to WiX could be an interesting option. I don't understand how I can use MSI's own patching support: it seems to impose a linear evolution of the product, with a well defined sequence of applying patches - and by all means, do correct me if I'm wrong. My first impulse is to integrate something like tallow/paraffin in the patch build system, and generate service packs as standalone installers with 1 component/file (performance of patches is not really critical, they are quite small). Coupled with Installshield's dynamic linking, this is bound to break the component rules in a systematic manner. Also, there's the open issue of uninstalling these patches when the main product is uninstalled. Can you provide some pointers on the best way to proceed ? Thank you ! -- Stelian ENE Installer Engineer, DevTech Freescale Semiconductor Work: +40 21 305 2064 Mobile: +40 728 052 499 This e-mail, and any associated attachments have been classified as: [X] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
