Once Bug 231062 is completed we will have the ability to produce MSI packages of Mozilla apps. To do this we're using the WiX toolset http://wix.sourceforge.net/. I've been using 3.0.5419.0 RTM to build against. If WiX 3.5 is released before I finish Bug 231062 then I would like to test against and take that version, but seeing as how that release has been pushed back to September and I would like to finish the MSI package stuff by the end of March that seems unlikely. I would also note that while I fully intend on finishing it, Bug 231062 has been attempted and failed enough times that it's probably worth waiting till I get close to done before WiX is added to MozillaBuild ;-)

I see that WiX provides an MSI. I'm not incredibly familiar with the MSI install process, does msiexec take common parameters for install location, etc? Can I just copy the current Python install line in the MozillaBuild package script? http://hg.mozilla.org/mozilla-build/file/7ff254547fcd/packageit.py#l103

(In reply to comment #1) > I see that WiX provides an MSI. I'm not incredibly familiar with the MSI > install process, does msiexec take common parameters for install location, etc? > Can I just copy the current Python install line in the MozillaBuild package > script? > http://hg.mozilla.org/mozilla-build/file/7ff254547fcd/packageit.py#l103 Yes, you should be able to copy that (modulo python2.5 => Wix )

So we can make the WiX / Mozilla Build upgrade path easier I suggest the main executables be renamed like we do with NSIS so it is simpler to upgrade to 3.5 when it is released. Kyle, any issues with doing this that you know of?

(In reply to comment #3) > So we can make the WiX / Mozilla Build upgrade path easier I suggest the main > executables be renamed like we do with NSIS so it is simpler to upgrade to 3.5 > when it is released. > > Kyle, any issues with doing this that you know of? Sounds great. We discussed this in person, but I'll summarize in the bug for posterity. Right now I'm working off of a weekly 3.5 release because 3.0 RTM has a bug in it (http://sourceforge.net/tracker/?func=detail&aid=2860637&group_id=105970&atid=642714) that bites us fairly hard. I've been using http://wix.sourceforge.net/releases/3.5.1728.0/ and have not run into any issues. I don't think we're going to end up using all of the toolset programs (for example, the MSI decompiler is probably useless to us) but we probably should go ahead and give them all version naming just to be safe/consistent. We might also need to rename the foo.exe.config files to stay in sync, but I don't know enough about managed code to be sure.

Kyle, do you know of any reason the zip build can't be used?

Nope.

I did a quick verification that light and candle both appear to work properly renamed... I'll check the rest as time permits

Ted, is this approach ok with you? Kyle is going to check if we can remove the sdk from the zip since it increases the size quite a lot. Thanks

We could always do what we did with NSIS by just getting this into MozillaBuild and figure out the best way to get the latest version available in MozillaBuild later. Ideally we would AC_DEFINE the path to the WiX directory instead of the exe's since three of them need to be used currently. Ted, this also removes the sdk from the WiX dir since it isn't needed and is around 26 MB in size on disk. If we ever need it we'll need to release an updated MozillaBuild but I don't foresee needing it.

Comment on attachment 454118 [details] [diff] [review] patch rev1 I'm ok with whatever approach you want to go with here. If you land whichever of these patches you want, along with the binaries, I'll spin a build with it.

Pushed to mozilla-build http://hg.mozilla.org/mozilla-build/rev/41693508c245 I went with the second patch but I didn't remove the WiX SDK... this can be tuned in future releases of MozillaBuild after we know more about what is required, etc.

I'm a tad concerned about how we're going to maintain multiple versions of WiX in MozillaBuild along with needing multiple WiX exe's during build. I think the best way to do this would be to set the WiX directory to be used during configure instead of the individual exe's and append each exe name to this path as needed during the build. The shell script would also contain the version so we can set the appropriate WiX dir for the version we want. There is probably a better way to do this but I think this suffices and should make things simpler when we do need to upgrade WiX.

Comment on attachment 456006 [details] [diff] [review] patch - add shell script to get WiX dir I don't know that I'm wild about this. We could instead just set env vars in profile-extravars.sh, like WIX_351728_PATH="$MSYS_MOZBUILD/wix-351728" then detect that in configure.

Here's a build with all the patches you landed: http://people.mozilla.com/~tmielczarek/MozillaBuildSetup1.5pre.exe

Sounds good to me.

Comment on attachment 456089 [details] [diff] [review] followup patch Pushed followup patch to mozilla-build http://hg.mozilla.org/mozilla-build/rev/317455928b6f

(In reply to comment #14) > Here's a build with all the patches you landed: > http://people.mozilla.com/~tmielczarek/MozillaBuildSetup1.5pre.exe Thanks Ted, everything is working well on trunk and 1.9.2 using this build.

btw: is there any concern about the WiX dir having a setup.exe since it is in the path? Just thinking about issues like what happened with vim's install.exe. The rest of the exe's seem unique enough.