is there a way to compile out custom actions?

[TurboFisch]

is there a way to compile out custom actions? features can have release flags, but it appears that custom actions can't or at least I don't understand how it is achieved.

[TsungH]

Unfortunately, I don't believe IS2012 supports this.

[Christopher_Pai]

Factor the custom actions out of your main project and into a merge module. Add the merge module to the feature(s) that require the custom action. Now when you build with flags that pick up that feature you'll also pick up the merge module and it's custom action.

Taken to it's logical conclusion you can end up with dozens of merge modules and a very flexible installer architecture. The merge module can also be authored using other tools giving you a blend of the best capabilities of multiple tools.

That is how I roll...

[TurboFisch]

well, that's not going to work as I need to use a nested msi, which is not available in a merge module project.

[Christopher_Pai]

Nested MSI's (concurrent installations) is a deprecated feature and should not be used:

http://msdn.microsoft.com/en-us/library/aa368010(v=vs.85).aspx

That said, a nested MSI is one MSI installing another MSI. Either way both MSI's have to be built and the merge module concept would still work. Trust me, it's possible, it just sounds like my description to you wasn't enough.

[TurboFisch]

I realize nested installs are deprecated, however, no other group/product will share the nested installers. So the servicing issue is really a low risk.

what I have is 2 installers, produced by a complicated set of Wix processes. There are hundreds of components I each of these. It would appear that it would be a lot of work to re-architect and I don't have the time for that or even test it.

Somehow I need to incorporate these outputs in our Installshield project, so that the customer will only have a single installshield to deal with.

If there was a way to change the output or convert to merge modules, that would interest me.

I looked at chained msi and pre-requisites, but they did not seem appropriate or scriptable.

[Christopher_Pai]

I've done many IS and WIX conversions/integrations and I'm fluent in both. It sounds like your question is more complex then filtering a custom action from an installer. In WiX, you would do this using preprocessor statements.

I once worked for a company where we had 250 developers and 500 total employees. Our engineering department used product line methodologies to create service families of core assets that could be composed in different combinations / variations with additional domain and product assets to create dozens of unique similar yet unique products. That happened on multiple branches and each product was basically the complexity of Visual Studio. A bootstrapper with multiple prereqs and MSI's with hundreds of features and thousands (12K-15K typically). IIS Meta, SQL, COM, Services and so on. I created an architecture of developer maintained WiX Merge Modules and InstallShield Basic MSI (heavily using Fetaure Trees and Product Configurations dynamically emitted at build time based on WiX XML definitions ) and was able to support the organization with just 2 setup developers. I probably could have done it with just 1 but you have to be able to take a vacation some time. 🙂

Just let me know if you ever want to have a 1 hour discussion of your situation. It should be possible to solve your installer problems and free up your time for other tasks.

[TurboFisch]

thanks. at the moment I'm experimenting with prerequisites as I can condition it to specific features just like merge modules.

at the moment, the setup.exe is not a combined into a single file, but creates a subdirectory "ISSetupPrerequisites". My requirement is that I must have a single installer.