I am using a WIX installer that is showing some brackets in the status line (see image below):
I haven't made changes to the WIX file, but only the installed files have changed. I did update WIX to v3.11, because this was required to use WIX in Visual Studio 2017. We use the standard WixUI.
These strings are listed in the C:\Program Files (x86)\WiX Toolset v3.11\SDK\wixui\WixUI_en-us.wxl file. A few lines from this file:
<String Id="ProgressTextRemoveFiles" Overridable="yes"><!-- _locID_text="ProgressTextRemoveFiles" _locComment="ProgressTextRemoveFiles" -->Removing files</String>
<String Id="ProgressTextRemoveFilesTemplate" Overridable="yes"><!-- _locID_text="ProgressTextRemoveFilesTemplate" _locComment="ProgressTextRemoveFilesTemplate" -->File: [1], Directory: [9]</String>
These strings exactly match what I see during installation. It seems only the ProgressDlg has this issue, but maybe other strings don't use expansion. Anyone has a clue?
Try to add the following line in your main wxs:
<UIRef Id="WixUI_ErrorProgressText" />
See my answer for the same question.
Related
I'm creating a bootsrapper and I want to remove links that are created during installation. So I write following step:
<Chain>
...
<ExePackage Id="removelnk" Cache="no" SourceFile="run.bat" InstallCommand="del "C:\Users\Public\Desktop\Parity UI.lnk"" />
</Chain>
Where run.bat is simply %* which allows to run arbitrary code as described here.
However, it doesn't work:
[19EC:0E2C][2018-06-16T18:32:27]i301: Applying execute package: removelnk, action: Install, path: C:\ProgramData\Package Cache\1608BB75347CD8C40187E5F3C0A969ED73A98D51\run.bat, arguments: '"C:\ProgramData\Package Cache\1608BB75347CD8C40187E5F3C0A969ED73A98D51\run.bat" del "C:\Users\Public\Desktop\Parity UI.lnk"'
[19EC:0E2C][2018-06-16T18:32:27]e000: Error 0x80070001: Process returned error: 0x1
[19EC:0E2C][2018-06-16T18:32:27]e000: Error 0x80070001: Failed to execute EXE package.
[0AE4:2B94][2018-06-16T18:32:27]e000: Error 0x80070001: Failed to configure per-machine EXE package.
[0AE4:2B94][2018-06-16T18:32:27]i319: Applied execute package: removelnk, result: 0x80070001, restart: None
[0AE4:2B94][2018-06-16T18:32:27]e000: Error 0x80070001: Failed to execute EXE package.
If I execute this command from log in my cmd then it works as expected. It even works without admin privileges.
What's wrong here?
Creating a Transform: You can use a transform to modify any MSI file - a very common use for a transform is to remove such shortcuts. You should be able to apply that transform on the command line specified in your bootstrapper - though I have never tried this with WiX bootstrappers.
Transforms are "little database fragments" that are applied to the original MSI. It changes the MSI file in memory and you can pretty much change whatever you want. You can create transforms with Orca or an equivalent free tool. Commercial tools - such as Advanced Installer - can also be used of course. In fact they have a nice little video showing the process (towards the bottom).
There is a long explanation of transforms (among other things) here: How to make better use of MSI files.
Applying a Transform: You apply transforms via the Transforms property during installation.
Quick Sample Command Line:
msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Quick Parameter Explanation:
/I = run installation sequence
/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.
Burn Bundle Details: I have not tried applying a transform in a Burn bundle (so I should have the sense not to answer), but the MsiPackage element is what you need I believe. I found this rather complicated sample of a Burn bundle source file - perhaps it is worth a look? It seems the magic is in the MsiProperty child element for the MsiPackage element.
UPDATE:
Burn Hello-World Style Example: Finally got to run a quick test on a Windows computer (was on a Linux one). Here is how you can apply a transform via Burn (minimal sample, just intended to show the basics, not pretending to be good markup).
Just inlining the warning: I hear some rumors that the application of
the transform in this way might not work in all cases - such as
repair. Please test thoroughly. It worked for my test. Also test upgrade scenarios (major upgrade for example).
This will apply the transform ShortcutDesktop.mst to the original MSI ShortcutDesktop.msi:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<!-- Maybe generate yourself an Upgrade-GUID here: https://www.guidgenerator.com/ -->
<Bundle Name="MyCoolTestApp" Version="1.0.0.0" Manufacturer="Someone"
UpgradeCode="PUT-GUID-HERE">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage SourceFile="ShortcutDesktop.msi">
<MsiProperty Name="TRANSFORMS" Value="ShortcutDesktop.mst" />
</MsiPackage>
</Chain>
</Bundle>
</Wix>
To build the Burn bundle BurnTest.wxs above:
set SetupName=BurnTest
candle.exe %SetupName%.wxs -ext WixBalExtension >> %SetupName%.log
light.exe %SetupName%.wixobj -ext WixBalExtension >> %SetupName%.log
And a link to a better Burn example on github:
https://github.com/frederiksen/Classic-WiX-Burn-Theme
Burn doesn't support batch files. Everything that modifies the machine should be done in a package.
Environment
Using a Bootstrapper project in Visual Studio 2012/Visual Studio 2013
Windows 7 Enterprise SP1
WixToolset 3.8
Details
Setup.exe never runs
The log file in AppData/Local/Temp/[WixBundleName][DateTime].log reads "Error 0x8007000d: Failed to load theme controls."
I have found that editing the Theme/Image[#ImageFile] value to anything other than Logo.png with cause the described error.
Changing the value back to Logo.png reverses the error.
Setting the value in Wix/Bundle/bal:WixStandardBootstrapperApplication[#LogoFile] appropriately changes the image and does not cause the setup.exe to produce an error.
Note I downloaded and used the default theme for HyperlinkLicense for my custom template with only change being the ImageFile attribute. It is improbable that this was a result of ill-formed xml.
In addition to JDennis' answer:
If you want to change the image, you should not modify the theme file. You need to define LogoFile attribute of the bal:WixStandardBootstrapperApplication element in your bundle:
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
<bal:WixStandardBootstrapperApplication LicenseUrl="" LogoFile="myLogo.png" ThemeFile="myHyperlinkTheme.xml" LocalizationFile="myHyperlinkTheme.wxl" />
</BootstrapperApplicationRef>
I am totally new to WiX, so of course my first task with WiX is to migrate an existing large installation program from WiX 2 to WiX 3. I've had a number of wrinkles most of which have been sorted, but I would be grateful for some suggestions with the following light errors. Since I am new to WiX, I want to list my whole process:
To create a WiX library:
candle.exe *.wxs
lit.exe -out "wixui_company.wixlib" *.wixobj
To generate the main MSI:
candle.exe main.wxs -o main.wixobj
light.exe main.wixobj -o Main_Installer.msi wixui_company.wixlib -ext WixUIExtension
This last command gives dozens and dozens of errors, but they all take the following form
error LGHT0091 : Duplicate symbol 'Dialog:LicenseAgreementDlg' found.
I have grep and re-greped, but the only references are the following:
In LicenseAgreementDlg.wxs:
<Fragment>
<UI>
<Dialog Id="LicenseAgreementDlg" ...
And in wixui_company.wxs
<Fragment>
<UI Id="WixUI">
<DialogRef Id="LicenseAgreementDlg" />
...
<Property Id="WixUI_WelcomeDlg_Next" Value="LicenseAgreementDlg" />
It is the DialogRef line that gives the error.
These both get referenced from wixui_company.wixlib in the main.wxs:
<UIRef Id="WixUI" />
FWIW, if I change either the ref to WixUI or the ref to LicenseAgreementDlg, duplicate errors go away, but instead I get symbol not found link errors. I migrated the original wxs files using WixCop, but under WiX 2 they all worked as is. I am guessing that this has to do with the move to put WiXUI in it's own namespace in WiX 3, but frankly I have no idea what to even try.
Any ideas on where things went horribly wrong?
Thanks,
Adam
"LicenseAgreementDlg" is the name of a dialog in the WixUIExtension that you're linking to with light.exe. Every dialog in an MSI database must have a unique identifier, so it's likely you've made a <UIRef> element to one of the standard WiX UIs ("WixUI_FeatureTree", "WixUI_Mondo", etc.), which includes WiX's LicenseAgreeementDlg dialog. You're then referencing your own LicenseAgreementDlg, so now you have two dialogs with the same name.
In this situation, you'd need to either rename your own LicenseAgreementDlg or remove it altogether and use the built-in one.
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.
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...