Install MSMs per feature

[gblockley]

How can I selectively install an MSM against a nominated feature?. I need to be able to install specific merge modules depending upon which features have been selected.

[ken rentz]

It would be nice to be able to control the inclusion of merge modules based on other conditions also. An example of this is Microsoft's speech files.

The supplemental voices are contained in a merge module. this module installs just fine on Windows Vista, but the voices do not work on this platform. To work around this I had to create a special install containing just the merge modules and then install that when the OS was something other than Vista.

[SteveDude]

The answer to this has always been to use the Import MSI/MSM Import Wizard (Requires Studio Admin Edition) and then incude that code in your own project.

Not super thrilled with this work around, but it does do the job.

[Justin Pava]

Steve,

As a follow-up to this... I assume that this import process is a one-shot static deal (as in. it grabs whatever that module is at the time that you run the import, but if it changes after that, you'd have to manually update that again)? I ask becuase we use a LOT of merge modules for common files that are used with multiple applications written in different install languages. Some of these modules are updating along with our main products, and so I need to be able to have it grab the current build version at any time (I already have our build process account for the fact that the modules need to be local - it copies the appropriate ones to the local build location from a built location on the network). However, it sounds like I wouldn't be able to actually use daily updating modules in a conditional manner with equivalently daily updating IA packages. Is that correct?

If so... well... this is going to make it quite difficult to use IA for a number of our applications, which have certain components (some of them in merge modules) that are installed conditionally based on install-time license checks and things like that.

[SteveDude]

You're right, in a away. What I do is create my own "Merge Module Scripts" and then include them in my installs (Include Script:). They can be shared easily that way. Also if you need to modify just change that one script and rebuild the projects sharing it. (Might need to manually copy it into your build folder).

I know, it's not pretty, but it works, for some things...but...

Wish one tool would do it all, it doesn't. Because of another bug in IA I still have to use IS for a couple of things and that's for making Merge Modules that get around a problem IA has with registering some files. Wise has the same problem and is actually worse. I use IA for all of the cool UI stuff, but the problematic files that IA cannot register I use IS built Merge Modules. Import the modules into IA MSI Script and forget about it. Builds will take hours not minutes and the Installation will appear to hang at the Windows Installer message.

[Justin Pava]

Yeah, I actually went back to using IS 9 for building the actual merge modules (had tried WixAware) becuase I really didn't want to have to update the registry information by hand every time the COM interfaces changed...

This doesn't sound like a really viable solution for a fully automated procedure, since you'd still have to manually update that one script file every time you update the module, right? Also, you're saying that for some of your modules, you don't even want to import them anyway becuase you run into a different issue in that case?

[SteveDude]

This doesn't sound like a really viable solution for a fully automated procedure, since you'd still have to manually update that one script file every time you update the module, right?

Yeah, if I catch your drift, but how are you automaticaly updating your modules? Are they yours or someone else's? If they're your's someone has to rewrite them or rebuild them anyway?

Also, you're saying that for some of your modules, you don't even want to import them anyway becuase you run into a different issue in that case?

Yes...specifically writing a fairly large amount of data to the registry.

[Justin Pava]

We have a pretty comprehensive automated build process that (among other things) gets latest on the source files contained in the modules, compiles them fresh, then recompiles the modules, then places the modules in (among other places) the proper place for IA to use the new version of them. That way all the developers need to worry about is committing their changes into source control, and the automation does the rest. Granted, SOME of the merge modules are stable and released files that don't need to be updated anymore, but those are really the easier ones ANYWAY. I don't want to have to go in and manually update anything along that path, becuase I don't want to cause possible release issues simply becuase I neglected to manually change or update something to reflect someone elses changes.

Now, I suppose if it's just the new file changing, well, PRESUMABLY the script wouldn't have to change for that so long as the new file made it to the proper place. But if COM registry info or something like that that would require an updated module structure changed, well, that would be a change in the file that would IMPACT the module, but I wouldn't necessarily know I needed to manually update things to match.