I have a .wixproj in VS 2010 that makes a MSI just the way I need it (using heat for harvesting in the pre build event). Now I need to distribute 3 versions of the same thing, that only need to differ in app.config settings, output MSI name, and some dialog stuff defined in some secondary .wxs files.
I was thinking about creating a console app that would take parameters and modify the .wixproj and .wxs and app.config files and then kick off MSBuild, but that seems like a lot of work.
What would be a better way to use WiX as a build factory so I can have it generate many customized MSI installers?
Thanks.
The WiX Preprocessor is your friend here. Using its values and conditional statements will help you to make "universal" sources, which will output various packages based on what you pass in.
Related
We have a solution, there are about 100 hundred projects in it. And we have around 20 installers which we created with vdproj.
I need to create WiX projects, which would create .msi instead of vdproj. I used dark.exe to generate wxs file out of msi and got binaries out of it.
I successfully created an msi file and everything was good.
But then I started thinking about it. If some of these projects are changed, will those changes be applied to the application after rebuilding of wix project? Or wxs will be referencing the old version and to update it someone will have to rebuild vdproj project to create new msi, then use dark.exe again?
I am sorry for a stupid question, it's my first time using wix and working with installers in general.
Thank you in advance
You've started on the right track. The VDPROJ outputs are .msi files, so using dark to convert those to wxs files is the right thing to do. Now that you have your wxs files (the base source file to build wix deployments), you can do away with the VDPROJ projects in your solution and only update and use the wxs files (I believe WiX has a visual studio project template available as well).
You'll have to update you wxs files with new assemblies or deliverable files as your projects change.
It is better this way then doing a wildcard pickup (something you can't technically do with WiX, anyway) as having explicit control of what goes on the target machine is preferred. I've seen many cases where developers carelessly add a reference as build output that isn't needed, and sometimes that reference cannot be redistributed per the license agreement or other legalities.
I wrote up a quick WiX preprocessor extension to grab some product version information from a file we keep in our root folder.
I'd like to keep this extension in the same solution as our WiX setup project, because it's easier to maintain. But the problem is that when testing, we use a Debug configuration, and when releasing a build, we switch to Release. This means that I have two extensions to deal with.
How would I tell WiX to grab one depending on the current configuration?
I've been looking at the reference paths in the WiX project's properties, and added "..\MyWiXExtensions\bin\$(Configuration)\" as a folder, hoping that it would pick up the MSBuild property, but that doesn't seem to work.
I've also looked at the build events. I could copy the output dll to my setup project's folder, but wouldn't that break references if I clean my solution?
I'm using WiX 3.7 and Visual Studio 2012.
I ended up using a post-build event on my extension that would copy the output to my wixproj's folder.
I just have to build my wixproj separately from the rest of the solution to prevent file locking issues when overwriting the dll. If file locking does come up, I just have to close VS and reopen the solution.
As a side note, referencing the project itself instead of the dll could be a nice feature to have in Votive.
I'm still very new to Wix so i'm trying to get my head around how it works. There is a lot to it and its a bit hard to get an understanding of it. If my Wix MSI Contains a bunch of patch files. Can i use a Custom Action with extract the files to a temp location, run a patcher, update the version with the patched file version and then run any other MSI actions?
I'm not really sure how to do this in the XML. I Assume there is some sort of execution sequence
Also if this is possible i need a way to dynamically add the patch files to the MSI during the Build. Can you base this on an output folder?
WiX is far better than installshield and the like, but without seeing your existing .wixproj this is hard to answer directly. You can use custom actions to do all of what you want, but it's not exactly the "WiX way", as that would not be easily reversible for a rollback or uninstall. Dynamically adding files during a build is absolutely possible. I must absolutely direct you to Ramirez' WiX: A Developer's Guide for Windows Installer XML. I got stuck building a complicated installer like this, and this book was invaluable.
What I can easily say is that for the patching portion, you can run exec tasks to run the patcher program and pass the patch files you want to run. You can dump all of these to a temporary directory to do it.
I am trying to integrate the automatic generation of MSI installers with my CruiseControl.Net installation. I can see how I can manually build an MSBuild file that calls candle and then light, but I need to make it build installers that can do upgrades, so can I use the BuildLabel (or something of that area) to regenerate new GUIDs for the newer versions?
I have already separated out the configurable parts of the WiX definitions, so it might be easier to hand roll a script or something.
Any help would be appreciated - especially working examples!
Thanks (as usual) in advance
Mark
Use Product/#Id="*" to let WiX generate product codes for upgrades. And you don't have to call candle.exe and light.exe manually; use the .wixproj templates to create MSBuild project files that use wix.targets.
Background:
I always try to ensure the following tenet in my projects:
After a fresh checkout a developer should be able to do all project related tasks with solely the contents of the combined folders.
Obviously, this isn't always possible (e.g. Visual Studio for Windows development). However, I really dislike having to install any third-party libraries or tools that are specific a project like log4net, NHibernate, NUnit, etc. There are number of reasons for this including:
For a given development machine, you may work on several different projects, all which leverage different versions of the same third-party library or tool.
Minimizing the environment setup requirements makes setting up new developers or machines much easier
Facilitates easier maintenance of automated builds
Assumptions/Contraints
I am currently using WiX 3 beta, but if there is way for either 2.0 or 3.0 please respond
I am using Visual Studio 2005
The IDE syntax highlighting is not a requirement.
Question:
Is it possible to avoid local installation of the WiX toolset and use flat files instead? If so, please explain how.
See Also:
First, build your WiX installer:
Create a new WiX Installer Project in Visual Studio 2005.
Build your WiX XML accordingly.
Now, to integrate the WiX toolkit into your source tree:
Copy c:\Program Files\Windows Installer XML v3\bin to a sub-directory in your source tree. I used WiX\bin relative to my .wixproj file.
Copy c:\Program Files\MSBuild\WiX\v3.0\ to a subdirectory in your source tree. I used WiX\v3.0 relative to my .wixproj file.
Either add the following code or replace the line that follows:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == ''>$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets</WixTargetsPath>
With the following lines:
<WixToolPath>$(MSBuildProjectDirectory)\WiX\bin\</WixToolPath>
<WixTasksPath>$(MSBuildProjectDirectory)\WiX\v3.0\WixTasks.dll</WixTasksPath>
<WixTargetsPath>$(MSBuildProjectDirectory)\WiX\v3.0\Wix.targets</WixTargetsPath>
As you can see, the WixToolPath, WixTasksPath and WixTargetsPath directives reflect the location of the folders I've instructed you to copy.
Rename your .wixproj to .csproj. This ensures that Visual Studio does not get confused by the .wixproj file but because the .wixproj is a valid MSBuild project, Visual Studio will be able to work with it.
Using this method, the WiX directory as described is about 9MB large.
I know with WiX 2, you can just download the executable files and the dll's to whatever directory your project is in. Then you create a .bat file to run candle.exe and light.exe with the parameters you need to build your installer.
That way, all your projects can have their own version of WiX with a disk drive hit of only about 4 megs each.
I'm not positive, but I think you can do the same with WiX 3.