On Thu, Mar 12, 2009 at 12:01 PM, Holmgren Mathias <mathias.holmg...@six.se>wrote:
> I just want uninstall to remove all application components (ie > exe+interop dll), regardless if those components where installed at > first install (primary scenario) or in a second "module" install > according to the secondary scenario. > If you want your MSI to remove post-install-generated content, you can use RemoveFile elements, assuming you know the folder where the content is located. Wildcards are allowed on the file name, but not on the folder. If you have subfolders to be removed, I think you'd have to write a custom action to handle that. If at all possible, I would really want to keep the integrity of "one" > app MSI, so professional organizations would use this same app MSI but > without the bootstrapper. This would reduce the corp confusion and team > maintenance pain of having multiple app MSIs. > Configuration in an MSI is usually handled via public properties (i.e. properties whose Id is all caps, like INSTALLDIR and DBSERVERNAME). These properties can be set through the UI, but they can also be defined from the command line, which would override the default value you would set. This allows an installation-savvy user do a command line install like this: msiexec /i MyApp.msi /qn INSTALLDIR="my path" DBSERVERNAME="DB1" SERVICEURL="http://myhost.com"; A novice user, who will simply "run" the MSI file, will get the UI and will have the default values you put in for those properties. WiX has an advanced template that allows users to click Install from one the early dialogs and skip over any customization dialogs. I think You should still include customization dialogs in the MSI for these properties. This supports the "semi-professional" user. That is, they know the customizations they want, but they don't know how to use msiexec from the command line. Or, maybe the bootstrapper itself can include the property values in > play so all we have to have per partner is a different bootstrap exe > (and the app MSI in distributed format can be identical for all > customers and partners while avoiding transforms altogether)? > Bootstrappers are usually pretty dumb. They are customized to say here are the products to be installed before I launch the final product installation. I'm not sure I understand your relationship with the users of the app. Who is going to run your installer? The partners? Or are the partners giving the installer to end users, and the partner relies on you, the author, to provide appropriate partner-specific defaults? Instead of generating different bootstrappers, I would generate multiple MSIs. This can be automated as part of your build process. The public properties' default value can be a variable you define. That variable can be passed on the command line in your build process. Assuming your app has the same third-party prerequisites for all partner distributions, the bootstrapper will have the same configuration for each customized MSI. My confusion here is not so much how a bootstrapper fits into this (or > rather not) but more about what would be *best practice* for this kind > of post install, extra MSI-module install scenario that does not > fragment the main installation scenario into a big mess of > sub-MSI-packages per Office version?? > When you configure the bootstrapper, you can either download the PIA installer file and include it in your distribution, or you can configure it to download it from a web site. That could be your own web site, or you might choose to use the Microsoft web site. If you choose to include the interop installers with your distribution, you could author your MSI to put them into a sub-folder within your installation. Then your app can be execute the provided installer since you know the name and relative location. I don't like this idea, myself. I would opt for downloads. In your app, I would show a dialog that includes a hyperlink that takes the customer to the Microsoft web site where they can download and run the installation for the PIA. I hope that my suggestions are appropriate for your scenario. If I've made any poor suggestions, hopefully somebody else will chime in. - Don Benson - ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
