I've recently added WiX to my continuous integration server, Team City. They key is to not have to install stuff on the build machines. WiX includes the install binaries that can be put right in your source tree. However the binaries do not include the files necessary for Custom Actions (CAs), so I had to include some extra files that come with the standard WiX developer install.
http://wix.codeplex.com/releases/view/99514 Then, update your .wixproj projects to point to the relative path to your wix binaries. See the Wix tags in <PropertyGroup>. <PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">x86</Platform> <ProductVersion>3.7</ProductVersion> <ProjectGuid>zzzzz</ProjectGuid> <SchemaVersion>2.0</SchemaVersion> <OutputName>My Installer</OutputName> <OutputType>Package</OutputType> <WixToolPath>..\..\InstallTools\wix\3.7.1224.0\</WixToolPath> <WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath> <WixTasksPath>wixtasks.dll</WixTasksPath> </PropertyGroup> If you're doing bootstrappers prerequisites with the GenerateBootstrapper command, you can do something similar in your project's bootstrapper to redirect them to a relative path so that the build machine doesn't need to have Visual Studio installed, or whatever puts them in the default Microsoft SDK package. <GenerateBootstrapper ApplicationFile="MyInstaller.msi" ApplicationName="My App " BootstrapperItems="@(BootstrapperFile)" ComponentsLocation="Relative" CopyComponents="True" OutputPath="$(OutputPath)" Path="..\..\Bootstrapper" /> Mark Freedman -----Original Message----- From: John Ludlow [mailto:john.ludlow...@gmail.com] Sent: Thursday, May 30, 2013 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices We're looking at simply making WiX part of the toolkit you need to build our solutions. We've tried this with some smaller projects and it's worked really well. Developers can follow up on their own impacts, and they can tell when they've broken the install. This increases build quality and frees up install developers from the "add a file, remove a file" monkey-work we seem to spend 80% of our time doing. Some of the developers grumbled a bit, but it's also been taken positively by others, and everyone gets a bit more respect for their poor, abused install developers. :) In fact, the main issues are related to integrating it into our build system (which is more down to the fact that we don't want to install stuff onto our build system - we want the build to be able to xcopy install whatever it needs). On 29 May 2013 18:46, <keith.doug...@statcan.gc.ca> wrote: > I don't know if our approach will work well long term since we are > still developing all of this, but we decided we'd build front end > utilities for developers to use with presets implicitly written out to > wxs for them (like Manufacturer and expected directories to install > to, etc.). This way in principle we could also have developers (or in > your case, a build server) drop off their files and an installer build > person / process can then pick them up with the front end to WIX. > > > > Keith Douglas > Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 > Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A > 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 > Facsimile | Télécopieur 613-951-1966 Government of Canada | > Gouvernement du Canada > > > -----Original Message----- > From: Drake, David [mailto:david.dr...@wizards.com] > Sent: May-29-13 1:41 PM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Wix dev and regular dev best practices > > I am attempting to bring an extra layer of automation to my area of > concern and have chosen to start packaging up each of our services > into .msi files for easier deployment and configuration. Part of > getting started is figuring out the best way to implement WIX > installers into our build system without causing impact on the > developers. My initial thought was to add wix projects to the various > solutions we have in source control, check in all of the WIX binaries > as mentioned in the WIX manual so the CruiseControl powered build > system can see them. I have set a post-build step in one of their C# > Projects to run Heat.exe and spit out a files.wxs file that contains > all of their output, and filter it through a transform.xsl to add in > the ServiceControl elements and strip out all of the useless garbage that > should not be installed. > > The problem with this is that it's going to cause the devs to have an > issue with opening the solution and having that one .wixproj project > fail to open, throwing up a pop-up and somewhat disrupting their flow. > > Is there a way to give them just the VS2012 plugin so the .wixproj > type is recognized, or should I just stay out of their solution files > and find some other way to run heat to harvest their output and go on > to build the .msi file? > > Is there some other approach that has been proven to work well when > the person creating and maintaining the installer creation and > deployment processes is not a direct member of the development team? > > Thank you, > > ~David Drake > CES Build Engineer > david.dr...@wizards.com<mailto:david.dr...@wizards.com> > > > ---------------------------------------------------------------------- > -------- Introducing AppDynamics Lite, a free troubleshooting tool for > Java/.NET Get 100% visibility into your production application - at no > cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ---------------------------------------------------------------------- > -------- Introducing AppDynamics Lite, a free troubleshooting tool for > Java/.NET Get 100% visibility into your production application - at no > cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
