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.
Related
I have an application with a bootstrapper that installs multiple components below it. The code below uses ninject to have a loosely coupled database layer.
With regards to the bundle/bootstrapper, I would like to move the database layer out into a separate msi in order to support optional data layer choices on install (e.g.: radio buttons to install SQLite/SQLExpress/MySQL etc..).
I am struggling to figure out how to get the install directory working though, as the database components needs to install into the root/install directory of the main application. (rather than using the gac etc).
How can I do this? I have tried the steps mentioned here: How to use properties to set the installation path? but to no avail. I must have something wrong.. but given the code is spread over 5(ish) files, it seems a little large to load here!
Any pointers to get started trying to implement this, or should I go ahead and upload the code?
The method you refer to should work. Note however that the name of the property given in
<MsiProperty Name="INSTALLLOCATION"
should match the name used in wxs file of the corresponding MSI package. Typically if the MSI was created based on WixUI_InstallDir template the name would be APPLICATIONFOLDER and in the default template without the UI it is INSTALLFOLDER.
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
My installer has to copy files into installdir... My application has around 2000 files and it is not possible for me to write the script to add each and every file to the installer.
Is there any option in wix so that I can add all the files or the entire folder consisting the files at once? I am new to wix and i didnt find any option in any tutorial for this... Please do assist me and thanks in advance.....
Heat is the WiX harvest tool. You can run it on a directory to generate the necessary WiX source code.
EDIT:
If you want to run heat before your VS project builds, add it to your project prebuild events as seen in the screenshot below (this is how I have my project setup to dynamically generate WiX source for our ever changing help content):
Note the -var wix.HelpSource switch that I have. The WiX source files generated by heat will set the location of the source files to that variable instead of hard-coding it. So the generated source will have components that look something like this:
<Component Id="Welcome.htm" Directory="Content" Guid="INSERT-GUID-HERE">
<File Id="Welcome.htm" KeyPath="yes" Source="!(wix.HelpSource)\Content\Welcome.htm" />
</Component>
And in my particular case, I define that variable on the Tool Settings screen of my WiX VS project to the relative directory ..\..\Help\Output as seen below:
NOTE: Harvesting files in this manner will cause the GUIDs of the components harvested to change every time you build. If you don't want your GUIDs to change, you may have to write some wrapper that calls heat to harvest the files, then updates your original WiX source, leaving all the GUIDs alone.
I'm using Visual Studio to build my wix file. So far I have one file Product.wxs and it's working for a simple install.
Now I want to add some custom dialogs. I think from the two articles below, I understand how to do it - after I get my environment set up:
http://blog.torresdal.net/2008/10/24/WiXAndDTFUsingACustomActionToListAvailableWebSitesOnIIS.aspx
and
http://www.merlinia.com/mdt/WiXTutorial2.msl
I downloaded the source, and I see 35 *.wxs file in this directory
wix35-sources.zip\src\ext\UIExtension\wixlib
This is where I'm starting to get lost.
Do I need to copy some (only the ones I want to change) or all these files to my Visual Studio Project. Until now, I have been running with none of these source files.
How does my Product.wxs know to use these files? Does it look at local directory first? Or do I have to rebuild some C# modules?
I included these lines in my Product.wxs, and it gave me the user interface at execution time:
<UIRef Id="WixUI_Mondo" />
<UIRef Id="WixUI_ErrorProgressText" />
Thanks,
Neal
Do I need to copy some (only the ones I want to change) or all these files to
my VisualStudio Project. Until now, I have been running with none of these source files.
Since you are already using WixUI_Mondo, I assume you want to customize that UI. Locate WixUI_Mondo.wxs in the wix sources, and copy that to your visual studio project. Rename the file to WixUI_MyCustomUI.wxs and change the UI Id attribute inside the file to Id="WixUI_MyCustomUI". You don't need to copy any other files yet; the dialogs referenced in the copied UI sequence are compiled into the wix tools as resources, so wix "knows" these dialogs by name.
In your product.wxs file, change the UI reference to <UIRef Id="WixUI_MyCustomUI" />. If you now rebuild your setup, the UI should still look exactly as WixUI_Mondo as we haven't customized anything yet.
If that worked, you'll probably want to customize or add a dialog. Again, you can start from an existing dialog by copying it from the wix sources. You'll also have to edit the WixUI_MyCustomUI.wxs file so that it uses your new dialog. Take a look at this other answer I wrote for an example.
How does my Product.wxs know to use
these files? Does it look at local
directory first? Or do I have to
rebuild some C# modules?
You do not have rebuild any C# modules. The only reason you downloaded the wix sources is because the existing UI sequences and dialogs are good examples to start from. In principle you could also ignore the wix sources and write these wxs files for the UI sequence and dialog definitions from scratch.
When you use the command line tools, you combine multiple wxs files by simply passing multiple file arguments and they will be compiled and linked together. If you use wix with visual studio, you just have to add the wxs file to the project. A non-trivial wix setup will typically be defined by many wxs files.
The content of a wxs file can container references to elements in other wxs files through elements such as UIRef, ComponentRef, ComponentGroupRef, DirectoryRef etcetera.
I have an application with several files that contain configuration parameters and other data that changes as the user uses the application. These files can change with newer versions of my software, but the user can also modify them (or they may be changed by the application itself). Basically, I'm looking for a solution to prevent the users' changes to these files from being overwritten but also a way to install the potentially updated files when the user upgrades my software.
With RPM on *NIX you could use the %config function to define a file as a configuration file and RPM would then rename the existing file (if it existed) and install the new one on an upgrade (maybe not ideal, but I could live with something like this for WiX).
I'd like to install my config files to a subdirectory or even a different name (e.g. default.cfg) and then use the <CopyFile> element in WiX to copy the files to their correct locations. This way, the default files would get removed on install and overwritten on an upgrade, but the actual user files would stay the same. Unfortunately with <CopyFile>, Windows Installer still wants to manage (and remove) the destination file.
I've also considered using the QtExec action in WixUtilExtension to basically do "copy default.cfg reallocation.cfg" but this wouldn't quite work and it is a bit of a hack.
What is the correct way to handle this?
My recommendation is usually to have the user editable content in a separate file and manage that via the application instead of the install. That also means the separate file is "user content" and should be left out of the install.
I've found trying to do migration of user data declaratively to be deceptively difficult. Trying to do it at setup time when you need to think through install, uninstall, repair, patching and rollback for all of those cases only makes it worse.
For example, what does the RPM behavior do on "repair". Copy the user data out of the way and replace it with a good file? That's probably correct 60% - 80% of the time. And uninstall, should the file be removed? That's tricky if the user is going to just upgrade to the next version.
Again, better to let them decide what to do with their tweaks to the configuration. IMHO.
I think there is no "clean" way to do this, because a msi project must be able to uninstall itself completely by design. I think the best way to solve this, is by using a custom action which executes a batch file and put your configfile update logic in that batch file. The custom action looks like this (only relevant parts):
<Directory Id="MYDIR" Name="MyDir">
<Component Id="update.cmd" Guid="YOUR-GUID">
<File Id="update.cmd" Name="update.cmd" KeyPath="yes"
Source="source\update.cmd" />
</Component>
</Directory>
<CustomAction Id='RunUpdate' Directory='MYDIR'
ExeCommand='[SystemFolder]cmd.exe /c update.cmd' Return='ignore'/>
<InstallExecuteSequence>
<Custom Action='RunUpdate' After='InstallFinalize'>NOT Installed</Custom>
</InstallExecuteSequence>