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
