I’m writing an MSI for using WiX 3.0 and I’m trying to figure out how to make it include all but some files from a directory without having to manually specify each and every attribute. Similar to a dynamic pickup in installshield.
An old installer I’m looking at for reference (which uses WiX 2.0) does the following:
A makefile to call a script that will copy all the necessary files to a separate directory structure that emulates how the final product should be installed.
another script to insert the attributes for each of the files in this temp folder to a partially completed wxs file.
WiX runs
I want to avoid this step and was wondering if there were some commands or pre-processor directives to achieve this WiX itself?
Also the 1st step above spits out some generated files (from a tool) which is then included into the wxs file. Is there a way I can emulate that as well?
You need to specify each file.
However, you can use Heat.exe to automatically generate a wxs file you can include as part of your build process.
I cheaped out with a non-solution, and zipped up the directory and it's files in the build script. The advantage of your current method is that MSI is aware of the files and they could potentially be key files (and thus patched/upgraded and/or repaired).
I'd look into saschabeaumont's suggestion about using heat. clearly a better solution
Related
I would like to create a script that will update files in the (default) install location with files from the source location where needed, based on the .wxs files that I have. I need to get this info from the wxs files, because the installation dir structure differs from the source location dir structure.
This would speed up my development cycle by not requiring a complete MSI uninstall/install when I have only recompiled one DLL for instance.
Is there functionality available in the Wix toolset that can give me a list of corresponding source and destination paths or would I have to implement everything including parsing of the Wix XML files myself?
I did not see anything relevant in the List of Tools section of the Wix documentation.
Alternative Approach: I would suggest using the commercial file and directory syncing and comparison tool Beyond Compare to copy files to the destination directory with ease if this is just for QA. I guess you can use post build steps too, but Beyond Compare is very nice and reliable. It has the features you need for just about anything related to comparison of files and folders (not affiliated). You can let the application just sit there and you can do a full comparison on the fly whenever needed. Essential software for deployment people. Alternatives exist of course (list).
I'm converting our current monolithic installer to use a WiX 3.7 Bundle/chain. We have several components that are now building into their own separately-maintainable MSI installers. My next task is to add all of these to a bootloader/bootchainer, but I've hit a snag.
A requirement for our individual installers is that they contain the version in the filename (i.e. MyApplication-5.4.22.msi). I don't see a tool like Heat for collecting MSI packages together, and I don't see a way to add an MsiPackage element with a wildcard to account for varying package names.
As a last resort, I can wrap the bundler inside of another MSBuild script that will 'autocomplete' the filenames and pass the paths in as variables to the bundler. I'm hoping someone can recommend a solution that works directly in the wxs or wixproj setting.
If the msi files are built with WiX Setup projects, the WiX Bootstrapper project can reference them, thereby creating useful WiX variables that are defined as the paths to the msi files.
See my answer here, as well as the list of variables here.
If that's not the case then you can write some MSBuild targets that run before the Build target to figure out the actual file paths. If the available standard and community MSBuild tasks aren't sufficient, you can write your own tasks, either by creating an assembly or using inline code. (And, of course, there is always the Exec task to shell out to a command-line program like cmd.exe, after which you can parse its output to extract the msi paths.)
I've just started looking at wix again now that it looks like installer projects are going to be deprecated from VisualStudio. We have a third party application that is "install via xcopy", which makes it hard for us to track in terms of versioning so we'd like to create an msi for it. There are several hundred files that are part of the installation.
I'd like to use heat to create the list of files for the installer, but I've heard that it's not good to use heat to create the wxs file more than once with autoguids because then your installer will have issues.
I was wondering if in wix 3.6, there was a command line parameter to heat which would take a previously generated wxs file as the source for guids? I want heat to autogenerate guids for any new files, but use the previous output of heat as a database for existing files.
If you use the -ag flag this will set the guids to be generated at compile time and as long as the path doesn't change the compiler will keep the same guid for each component. Rather than use a command-line to do the harvesting it is better to edit the *.wixproj file and add a HeatDirectory element.
I am in the process of migrating all my projects one by one from Installshield to Wix and I would like to find out the best way to deal with env specific files.
Our current process is:
Using Installshield we create a base MSI and a Transform file which would install the base MSI and a directory structure with files present in the current directory. Ofcourse in my source control, I have separate config files for different environments and my Deployment script picks up the right set of files and puts them in a staging location.
For example, Current dir looks like as follows:
sample.msi
sample.mst
test\apps\docs\global.config
test\files\docs\global.config
sample.msi gets installed and the above directory structure gets copied to the target location.
During Uninstall the directory structure gets removed as well.
I tried to recreate this behavior using CopyFile element but during uninstall the copied files stay and do not get removed. Is there another way to achieve this?
I understand the way we do our packaging might not be the best way to get around our requirements. If someone has a better way to do this, please let me know.
I am still very new to Wix and I haven't looked at any of the wix extensions so wouldn't know what else is out there.
As always, any help is greatly appreciated.
Do these files really have to be seperate from the msi?
Using wix you could put them all into the msi and install them based on certain conditions like settings properties or using a custom action. Doing it that way should make it rather easy to let the msi create the directories and copy the files, and also remove them when uninstalling.
Conditions would work like this:
<Component Id='MyComponent' Guid='PUT-GUID-HERE'>
<Condition><![CDATA[YOUR-PROPERTY = "SOME_STRING"]]></Condition>
<File Id='readme' Name='readme.txt' DiskId='1' Source='readme.txt' />
</Component>
A CustomAction in Wix can be a .net dll, the manual explains how this is done here:
Adding Custom Actions
IF you have the WIX Toolkit installed you just need to create a Custom Action Project.
I'm using heat.exe to generate WiX file fragments.
I've done this via adding a post build step to my web site project in visual studio, such that every time a build is done, any new files in the web project are picked up and new wxs file fragments are created. These file fragments are copied directly into the wix setup project, such that when the setup project is built, it will include all the newly added content files into the msi.
I noted last time I looked that every time heat.exe regenerates the wxs file fragments, it creates new guids (but apparently not new component ids).
At any rate, I'm very new to WiX/heat, so the question is - should I be autogenerating the wxs files every time, e.g. how will this effect things in production when new versions of the website are released and installed/uninstalled? are there any reasons why I should not be autogenerating and including these file fragments on every build?
There are two main lines of thought on this sort of scenario; which one you follow depends on which risk freaks you out more. Do you worry more that you may not include some changes which become necessary in the future because nobody tells you and you didn't update your one-time generation, or do you worry more that two .msi files created with results from autogeneration will not upgrade well not let you know if important files go missing?
Personally I tend towards believing that autogeneration results in harder-to-fix problems, so I would suggest generating these only when you know something has changed, and then verifying the differences are what you expect.