I have recently converted visual studio setup projects to wix project. Everything great, except that you have to ist every file manually. Is there something similar to adding project output (VS studio setup project). I read something about HeatProject task but don't know how to use it, could not find any documentation or example of the same.First question,is it possible to add project output instead of adding files one by one if yes then how?
Heat offers same functionality like tallow, or paraffin. Paraffin will generate .wxs fragment file containing list of all files which will be deployed. Using parameters you can set which files you want and more.
Example
%1\Paraffin.exe -dir "..\..\..\..\Web\HostDir" -dirref INSTALLLOC -custom APPL ..\..\WebFragment.wxs -guids -ext .csproj -direXclude obj -multiple
We use heat.exe to harvest our app files as follows. The %FULL_PUBLISH_PATH% is the full path to the directory that we instructed msbuild to publish the webapp to.
"%WIX_TOOLS_PATH%heat.exe" dir %FULL_PUBLISH_PATH% -dr WEBAPPLOC -ke -srd -cg ComponentNameToUse -var var.publishDir -gg -out FileNameToUse.wxs
Related
I have a Windows application which is built using MSVC and packaged as an .MSI file using WiX. The whole build is managed by cmake and WiX is invoked using the CPackWIX module.
I am now trying to extend the build environment to also build an .APPX package. I am following the official documentation by FireGiant.
After installing the WiX Expansion Pack, I have added the extension FgAppxExtension.wixext by appending it to the variable CPACK_WIX_EXTENSIONS like so:
SET(CPACK_WIX_EXTENSIONS WixUtilExtension FgAppxExtension.wixext)
I have then edited the .wxs source code as indicated here.
The build runs without any errors but creates no .APPX package. It only creates the usual .MSI package. In the wix.log file I see the line:
"C:/Program Files (x86)/WiX Toolset v3.11/bin/light.exe" -nologo -out "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/MyApp-1.15.0+115-default-eb4abec2e9d2+.msi" -ext "FgAppxExtension.wixext" -ext "WixUIExtension" -ext "WixUtilExtension" -cultures:de-DE;en-US "-loc" "C:/dev/MyApp/resources/packaging/win/WIX.Texts.de-DE.wxl" "-loc" "C:/dev/MyApp/resources/packaging/win/WIX.Texts.en-US.wxl" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/directories.wixobj" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/files.wixobj" "F:/dev/AusweisApp2-build/_CPack_Packages/win32/WIX/features.wixobj" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/main.wixobj"
for the .MSI file, but no line for the .APPX package.
The documentation says that after adding a reference to FgAppxExtension.wixext
... the build process will attempt to create AppX packages.
but this does not happen.
Note that adding a wrong extension in the cmake file will result in a build error.
Changing the .wxs source code without adding the extension will also result in an error:
The Product element contains an unhandled extension element 'fga:Appx'.
So I think the FgAppxExtension.wixext extension is loaded correctly, yet no .APPX package is built.
Do you have any hints?
Loading the FgAppxExtension.wixext extension isn't enough to build the .appx package while building the .msi package. FgAppxExtension does that using MSBuild, which isn't in play when using CMake.
When you're not using MSBuild, you can invoke the FireGiant.Appx.exe tool after Light.exe has produced the .msi and .wixpdb files.
I'm using cmake/cpack to build my project with WiX.
cmake runs heat.exe (or something similar) which produces files.wxs that contains the files of my project in the following format:
We'll assume a single file named a.txt inside a folder named "bin". The project is built in NewFolder on the Desktop.
<DirectoryRef Id="CM_DP_bin">
<Component Id="CM_CP_bin.a.txt" Guid="*">
<File Id="CM_FP_bin.a.txt" Source="C:/Users/mindlessbot/Desktop/NewFolder/_CPack_Packages/WIX/packageName/bin/a.txt" KeyPath="yes"/>
</Component>
</DirectoryRef>
After the MSI is created, the whole NewFolder is moved in a different directory (on our server). As a result, when I try to create a WiX Patch using the output .wixpdb, I get the following error:
error PYRO0103 : The system cannot find the file 'C:/Users/mindlessbot/Desktop/NewFolder/_CPack_Packages/WIX/packageName/bin/a.txt'
After some googling, I found out that the .wixpdb contains references to the files, which have changed location, so of course it can't find them. I found a thread where someone provided the commands to use bindpaths, however since I'm using cpack I can't directly call them.
So how should I got about doing this?
Some additional info:
My project contains multiple wxs files (not sure if it makes any difference)
The cpack command is:
path/to/cpack.exe -G WIX --config path/to/config.cmake
The patch command is run separately:
torch.exe -p -xi path/to/oldInstaller.wixpdb path/to/newInstaller.wixpdb -out path/to/patch.wixmst
candle.exe path/to/patch.wxs -out path/to/patch.wixobj
light.exe path/to/patch.wixobj -out path/to/patch/wixmsp
pyro.exe path/to/patch.wixmsp -out path/to/patch.msp -t PatchBaselineID path/to/patch/wixmst
In the event that you would like to build your MSIs on one machine, but build the patch on another, I recommend using the .wixout approach rather than relying on the .wixpdb approach. A .wixout file may be generated by the same WiX Toolset CLI tool that is used to build the MSIs, light.exe. The .wixout
Full documentation on the WiX Toolset linker, light.exe, may be found here. The following is an example use of light.exe to build a .wixout file:
"C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe" "/path/to/Some.wixobj" "/path/to/Another.wixobj" "/path/to/AndYetAnother.wixlib" -bf -xo -out "/path/to/MyInstaller_v1.wixout"
So now let's breakdown what these command line parameters are for:
"/path/to/Some.wixobj" "/path/to/Another.wixobj" "/path/to/AndYetAnother.wixlib" - These are the compiled outputs of WiX source files, they may be either .wixobj files (generated through candle.exe) or .wixlib files (generated through lit.exe, a way of consolidating .wixobj files into one, shareable library).
-bf - This switch causes all of the files to be bound int the resulting .wixout file. This is what removes the need to have the exact folder structure on the target machine when building patches, because the files are carried with the .wixout file.
-xo - This switch tells the linker to output an XML representation of the MSI, instead of the actual MSI. This is required to use the -bf switch.
-out "/path/to/MyInstaller_v1.wixout" - This tells the linker where to output the .wixout file.
Once you have the capability of generating .wixout files, the torch.exe command can be modified to run based on .wixout files instead of .wixpdb files and their associated folder structures. The following is how I would modify your torch.exe command to use .wixout files as opposed to .wixpdb files:
torch.exe -p -xi "path/to/oldInstaller.wixout" "path/to/newInstaller.wixout" -out "path/to/patch.wixmst"
So, all in all I really like this approach, and generally I make my build process produce both an .msi and a .wixout file. This allows us to cache various builds/versions of our installer as .wixout files, and then the process of creating a patch between various versions of the .wixout files becomes relatively easy.
I have a Compressed file (Self-extracting) that was included as a ExePackage for the current BootStrapper project I'm working on.
I was asked to Unzip the package before including it in the BootStrapper, so that the end user doesn't have to unzip the file before starting the install process of that package.
Excluding the install application, there is two folders (win32 && win64) that contain 288 files each, I need to create a PayloadGroup out of these files. I started doing this by hand, but after looking at Heat element, I saw that Heat can generate Payloadgroup.
How can I harvest from the directories the Payloadgroup that is required for this package.
Doing this manually is a very long process ...
If using Visual Studio you're supposed to be able to go in your setup project's references and click on the reference in question and set Harvest to true.
If I recall this had some issues, and some online sources said it wasn't working for them, I'm not sure at the moment. Which is why I called heat from the command line in a post-build event. Something like this:
call "$(WIX)bin\heat.exe" dir "$(TargetDir)." -var var.$(ProjectName).TargetDir -dr INSTALLFOLDER -cg Binaries -gg -g1 -ag -scom -sreg -sfrag -srd -o "$(SolutionDir)Setup$(ProjectName)\$(ProjectName).Binaries.wxs"
You can even specify an XSLT transform that filters your generated wxs file. For more info check this helpful blog post
I implemented heat.exe dir -generate payloadgroup in v4.0 (https://github.com/wixtoolset/issues/issues/3470). In v3.x, the -generate option was only supported by project harvesting (heat.exe project ...).
I am new to using WiX so this my be a dumb question. I am trying to keep the GUID generated by the harvest tool (heat.exe) consistent for files that I am packaging. Everyone seems to say that as long as the file path and sub path remain same heat.exe will generate the same GUID for a file. Unfortunately, I am not seeing that behavior. My workflow is as follows.
Copy all the deliverable files to a staging directory during my build process. Then run heat.exe in the staging directory to generate the component fragment wxs file. Before I copy the file into the staging directory I clear all my old files.
I want to add the generated wxs file into my source control so that I can achieve minor upgrades. If my understanding is correct for me to achieve that I need to have consistent GUID across my builds so that I can track them.
The command line I use for generating the wxs file is as follows:-
c:\foobar\build\>C:\win32\wix-3.7.1224.0\heat.exe dir . -cg MyCG -dr INSTALLDIR -g1 -gg -nologo -sreg -suid -t C:\foobar\src\support\packaging\wix\foo.xslt -var var.foobarSource -out c:\foobar\src\support\packaging\wix\foo.wxs
What I see that the GUID generated are different during each run. Is there was a way for me to keep GUID consistent.
You should specify -ag flag.
-ag
Auto generate component guids at compile time, e.g. set Guid="*".
As long as your file paths are the same, generated GUID's will be the same for files.
When using Heat to auto generate it seems to create a whole bunch more components than what we want to actually ship.
For instance, Have a service that needs to be installed, so we want to do service registration stuff, and it is also a com component so we want to do com registration. This is all in an MSVC# project and including the project into the install project in wix automatically ran heat on it (I just meant to setup a dependency for build) and the output included hundreds of components.
If you want to allow for some dynamic portion - say change to the com registration - without including everything - like pdb files - how is this best managed?
When you include this heat file into your project, how would you specify which components make up which features and which get ignored?
You can specify the parameters along with which extension files you want and which to exclude.
Example
%1\Paraffin.exe -dir "..\..\..\..\Application" -dirref INSTALLLOCATION -custom App ..\..\AppFragment.wxs -guids -ext .vspscc -ext .cs -ext .resx -ext .csproj -ext .exclude -ext LocalAppSettings.config -ext .pdb -direXclude UITests -direXclude obj -direXclude Netrics -direXclude XSLT -multiple