Re: [WiX-users] Wix dev and regular dev best practices
We have the WiX tool installed on a shared drive on the network; for building the installer we use the commandline tools in the Project Property Sheets. This way the developers in our team don't need to install WiX but will still use it. Our devs build the apps, test it themselves and put it through to test. During their build they can deceide to test with or without the MSI, build the buildserver basically only generates MSI files for testing. Then we have one project (not generally used b the developers) which generates one set MSI for the entire set of applications. (One set consists of a DBx86, DBx64, ServerApplication and ClientApplication component and some special components (like terminalregistration tools, XML server, webservice controller, etc) Albert van Peppen -Oorspronkelijk bericht- Van: Alain Forget [mailto:afor...@cmu.edu] Verzonden: 31 May 2013 21:43 Aan: 'General discussion for Windows Installer XML toolset.' Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices +1 The chasm between getting things working in a development environment and getting them working seamlessly in the deployment environment (by end users) is a lot wider than some may be willing to admit. Alain -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: May 31, 2013 15:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices If it doesn't get built, it won't get tested. Period. Dev's have a tendency to consider installer building a waste of time (they always think they can do it better with a 3rd-party zip lib and some sort of XML config document) until it's one week before beta and suddenly you need to shake the bugs out of code that should've been tested since the beginning of the iteration six months prior. Push back HARD on any suggestion that building the installer is expendable. It's one of Wix's greatest strengths, and the installer is the first view a consumer will get of your product. If it isn't a good impression, it will have disproportionate impact. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Drake, David [mailto:david.dr...@wizards.com] Sent: Friday, May 31, 2013 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices Albert, Do you require your regular code writing devs to install Wix on their boxes so they don't get errors opening the wixproj files in the main solution, or do you keep the .wixproj files off in their own little solution so the devs don't notice? Also, do your devs handle the installers, or does someone other than the main app coders do that? Thanks, ~David -Original Message- From: Albert van Peppen [mailto:alb...@insad.nl] Sent: Thursday, May 30, 2013 23:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices We use a lot of (VS) Project Property Sheets. For WiX we have defined several property sheets for this. Our solution gives us the possibility to change the location where WixTools are etc. This way we can easily switch between WiX versions as well (assuming the schema, on what we use, hasn't been broken) Just my 2 ct ;) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: John Ludlow [mailto:john.ludlow...@gmail.com] Verzonden: 30 May 2013 17:06 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices @Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: 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 ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion
Re: [WiX-users] Wix dev and regular dev best practices
We use a lot of (VS) Project Property Sheets. For WiX we have defined several property sheets for this. Our solution gives us the possibility to change the location where WixTools are etc. This way we can easily switch between WiX versions as well (assuming the schema, on what we use, hasn't been broken) Just my 2 ct ;) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: John Ludlow [mailto:john.ludlow...@gmail.com] Verzonden: 30 May 2013 17:06 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices @Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: 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 ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion OutputNameMy Installer/OutputName OutputTypePackage/OutputType WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPathwixtasks.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
Re: [WiX-users] Wix dev and regular dev best practices
Albert, Do you require your regular code writing devs to install Wix on their boxes so they don't get errors opening the wixproj files in the main solution, or do you keep the .wixproj files off in their own little solution so the devs don't notice? Also, do your devs handle the installers, or does someone other than the main app coders do that? Thanks, ~David -Original Message- From: Albert van Peppen [mailto:alb...@insad.nl] Sent: Thursday, May 30, 2013 23:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices We use a lot of (VS) Project Property Sheets. For WiX we have defined several property sheets for this. Our solution gives us the possibility to change the location where WixTools are etc. This way we can easily switch between WiX versions as well (assuming the schema, on what we use, hasn't been broken) Just my 2 ct ;) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: John Ludlow [mailto:john.ludlow...@gmail.com] Verzonden: 30 May 2013 17:06 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices @Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: 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 ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion OutputNameMy Installer/OutputName OutputTypePackage/OutputType WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPathwixtasks.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
Re: [WiX-users] Wix dev and regular dev best practices
If it doesn't get built, it won't get tested. Period. Dev's have a tendency to consider installer building a waste of time (they always think they can do it better with a 3rd-party zip lib and some sort of XML config document) until it's one week before beta and suddenly you need to shake the bugs out of code that should've been tested since the beginning of the iteration six months prior. Push back HARD on any suggestion that building the installer is expendable. It's one of Wix's greatest strengths, and the installer is the first view a consumer will get of your product. If it isn't a good impression, it will have disproportionate impact. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Drake, David [mailto:david.dr...@wizards.com] Sent: Friday, May 31, 2013 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices Albert, Do you require your regular code writing devs to install Wix on their boxes so they don't get errors opening the wixproj files in the main solution, or do you keep the .wixproj files off in their own little solution so the devs don't notice? Also, do your devs handle the installers, or does someone other than the main app coders do that? Thanks, ~David -Original Message- From: Albert van Peppen [mailto:alb...@insad.nl] Sent: Thursday, May 30, 2013 23:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices We use a lot of (VS) Project Property Sheets. For WiX we have defined several property sheets for this. Our solution gives us the possibility to change the location where WixTools are etc. This way we can easily switch between WiX versions as well (assuming the schema, on what we use, hasn't been broken) Just my 2 ct ;) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: John Ludlow [mailto:john.ludlow...@gmail.com] Verzonden: 30 May 2013 17:06 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices @Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: 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 ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion OutputNameMy Installer/OutputName OutputTypePackage/OutputType WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPathwixtasks.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
Re: [WiX-users] Wix dev and regular dev best practices
+1 The chasm between getting things working in a development environment and getting them working seamlessly in the deployment environment (by end users) is a lot wider than some may be willing to admit. Alain -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: May 31, 2013 15:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices If it doesn't get built, it won't get tested. Period. Dev's have a tendency to consider installer building a waste of time (they always think they can do it better with a 3rd-party zip lib and some sort of XML config document) until it's one week before beta and suddenly you need to shake the bugs out of code that should've been tested since the beginning of the iteration six months prior. Push back HARD on any suggestion that building the installer is expendable. It's one of Wix's greatest strengths, and the installer is the first view a consumer will get of your product. If it isn't a good impression, it will have disproportionate impact. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Drake, David [mailto:david.dr...@wizards.com] Sent: Friday, May 31, 2013 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices Albert, Do you require your regular code writing devs to install Wix on their boxes so they don't get errors opening the wixproj files in the main solution, or do you keep the .wixproj files off in their own little solution so the devs don't notice? Also, do your devs handle the installers, or does someone other than the main app coders do that? Thanks, ~David -Original Message- From: Albert van Peppen [mailto:alb...@insad.nl] Sent: Thursday, May 30, 2013 23:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices We use a lot of (VS) Project Property Sheets. For WiX we have defined several property sheets for this. Our solution gives us the possibility to change the location where WixTools are etc. This way we can easily switch between WiX versions as well (assuming the schema, on what we use, hasn't been broken) Just my 2 ct ;) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: John Ludlow [mailto:john.ludlow...@gmail.com] Verzonden: 30 May 2013 17:06 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices @Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: 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 ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion OutputNameMy Installer/OutputName OutputTypePackage/OutputType WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPathwixtasks.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
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.commailto: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
Re: [WiX-users] Wix dev and regular dev best practices
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 ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion OutputNameMy Installer/OutputName OutputTypePackage/OutputType WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPathwixtasks.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
Re: [WiX-users] Wix dev and regular dev best practices
@Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: 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 ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion OutputNameMy Installer/OutputName OutputTypePackage/OutputType WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPathwixtasks.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
[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.commailto: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
Re: [WiX-users] Wix dev and regular dev best practices
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.commailto: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
