I've just been assigned a task of working (learning) WIX. To better understand the dialog handling and stuff, I found many references of "just get..." and then WixUI_InstallDir.wxs and InstallDirDlg.wxs (and obviously the others out there).
I've searched all over (several hours) and have YET to actually find the raw .WXS files these other links have directed me to.
Thanks for the help...
In case you are looking where wxs files are in the source tree, for 3.6 they are here:
src/ext/UIExtension/wixlib
And as AntonyW already pointed out the source can be downloaded from codeplex. This is the link for version 3.6:
http://wix.codeplex.com/SourceControl/list/changesets?branch=wix36
The lastest version is available through this direct link:
http://wix.codeplex.com/SourceControl/latest#src/ext/UIExtension/wixlib/InstallDirDlg.wxs
For version 3.5, the source code is at http://wix.codeplex.com/SourceControl/list/changesets?branch=wix35
The files can be found in the folder where Wix Toolset is installed.
C:\Program Files (x86)\WiX Toolset v3.11\SDK\wixui
And here's the latest source files. Thanks for the help.
http://wixtoolset.org/releases/v3.7.1015.0/wix37-sources.zip
Related
Since pulling changes, building my InstallerBootstrapper project in Visual C# 2010 fails with:
Could not find a part of the path "WiX Toolset v3.8\bin\IA64\burn.exe"
Indeed this directory does not exist, but it never did and the InstallerBootstrapper was building correctly before pulling.
The .wixproj and .wxs have not changed.
I reviewed the changes but can't seem to find what change could have caused that.
No file in the whole solution contain the string "IA64".
I have not updated WiX since a few months.
Google does return anything with these words.
Any idea what could have happened?
For some unfathomable reason, InstallerBootstrapper was configured to use IA64:
This happened when I re-imported the Installer et InstallerBootstrapper projects into the solution. No idea why, but it can be fixed by editing the solution file or using the COnfiguration Manager.
I should have searched for the lowercase string too.
In my WiX 3.5 project I'm including a wxs file via a link. I.e., the wxs file is not in the project folder, it is fairly far away in the folder structure, and is included using Visual Studio's "Add as a link" facility.
This is working fine. But it does have the strange side-effect that WiX creates the obj file for the included wxs in a strange location, creating several folders to somewhat (but not correctly) mimic the path structure between the WiX project folder and the folder where the wxs file is located.
Is there any way to avoid this, so WiX creates this obj file in the same place as the other obj files, or alternatively creates it next to the wxs file, and not half way in between?
I always thought this is what -out command-line parameter of candle.exe is for. Have you tried playing with it?
It turns out this is a bug in WiX 3.5, and has been documented in a blog entry here:
http://www.paraesthesia.com/archive/2011/02/07/wix-3-5-2519-0-incorrect-intermediate-object-path-for.aspx
The blog article also helpfully provides a work-around, although it didn't quite work for me. For my situation I had to add an extra backslash to the path, so instead of
<ObjectPath>obj\$(Configuration)</ObjectPath>
I needed to specify
<ObjectPath>obj\$(Configuration)\</ObjectPath>
Thanks to Travis Illig for the blog article, thanks to Edwin Castro on the WiX-Users mailing list for pointing me to the blog article, and thanks to Yan Sklyarenko for his help too.
EDIT:
The plot thickens - it's not a bug, it's a feature!
And it's not in WiX, per se, but in Votive / MSBuild.
https://sourceforge.net/mailarchive/message.php?msg_id=27244936
Anyway, the important thing is that it's easy to fix with the work-around suggested by Travis Illig in his blog article.
I've implemented the MSBuild Community Tasks from tigris to my C# Project.
My Problem is that im not alone working on this project, but i dont want everyone to install the MSBuild Community Task on his local PC.
Without MSBuild Community Task you're not able to compile the project.
So my idea was to make a small workaround, i want to include the Install-Files to my project and copy it with a precompile-command to the MSI-Install-destination
But i dont know where the MSI saves its files.
Does anyone know how to find out where the MSI File copies the included file to?
Or does anyone have a better idea?
Thanks, Alex
It solved my problem executing the MSI-File with the command-shell, I've changed the TargetDir to C:\Temp\MyMSI and the generated folder-structure told my where it's saving the files to.
msiexec /a "MyMsi.msi" /qn
TARGETDIR=C:\Temp\MyMSI
I have several folders files included in my Wix based installer. One of the folders may exist on the target machine already outside of any MSI installation. I do not want to replace the folder or files if they already exist for just one of the folders. It might be OK to not replace the files if they are older. Is there anything I need to specify or is this the default behavior?
The definitive answer is in the MSI SDK here: http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx
If this is a repeat question, please direct me to the existing solution. I wasn't able to find a matching query.
We currently use InstallShield. I'm attempting to covert a project with 407 files to a WiX3 installation package. I tried using heat.exe to do some of the automation but I get the following warning for almost every file:
c:> heat dir "c:\projectDir\projectA" -gg -ke -template:Product -out "c:\install\projectA\heatOutput"
heat.exe: warning HEAT5150 : Could not harvest data from a file that was expected to be a SelfReg DLL: c:\projectDir\projectA\plugin1.dll. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpful to diagnose the failure: Unable to load file: c:\projectDir\projectA\plugin1.dll, error: 126.
Q: Is it normal for this warning to be reported for every file?
If there's a current "How To create/convert to your first WiX install project with many files" tutorial, please point me to it. The key requirement is "with many files".
PS. I know that WiX is designed for incremental install project creation but it would be nice to know if there's an automated way to convert existing install projects.
If there's a current "How To
create/convert to your first WiX
install project with many files"
tutorial, please point me to it. The
key requirement is "with many files"
You can take the msi file generated with installshield, and then decompile it with the dark.exe tool which comes with wix. As you can see in this diagram, dark.exe generates wxs files from a msi file.
You can use it like this:
dark installer.msi decompiled.wxs
See dark /? for more information.
edit: I don't use Votive, but AFAIK it should be able to handle the wxs files generated by dark. Did Votive show you an error?
edit2: wixproj files are just for visual studio and msbuild integration. The core tools don't know or use this format. Simply create a blank wixproj and add the wxs file to it from visual studio.
edit3: You should not compare the size of the wxs file to the msi file size. Like an installshield project file, a wxs does not contain the files to install. It only references them. Your installshield project file is not 70MB large either. If you want to extract the binary files from the MSI, then you should use dark.exe with the -x <path> switch.
Are you trying to extract data from x64 DLL's? That doesn't really work...