I'm trying to develop a Wix project. I'm using Wix 3.6, and everything goes perfect, except when I try to change the default interface of Wix to the WiUI_Mondo one.
I do the following to change the interface:
Add reference to WixUIExtension.dll
Add <UIRef Id="WixUI_Mondo" />
With these simple steps, I should be able to change the interface of my Wix installer. Instead, it is launching an error like this:
Error: ICE17: Bitmap: '
And no more text after the simple comma.
Any idea on why is this happening??
EDIT: This mistake comes from several .wxs files, such as PrepareDlg.wxs, FilesInUse.wxs...
I don't know the exact reason, but you can see in msdn what ice17 is testing:
ice 17 documentation
Related
I am using a WiX bundle with Xeam Visual Installer as a bootstrapper UI application.
What I would like to do is set some variables inside the Custom Actions that my MSI is running, and I have figured out how to do that. I can see in my logs that the variables are being set.
My problem is I hoped that I would be able to read these variable and display them on the last page of my bootstrapper UI. Out here the variables still show as empty strings.
If you are familiar with Xeam, I am trying to access them like this:
MyProp = Bootstrapper.Engine.StringVariables["MY_PROP"];
Similar to the way you read and set properties during the initial bootstrapper workflow, before everything is sent to the MSI.
Has anyone else tried to do this. Should it be possible or are there any other solutions you can suggest?
This is apparently not possible. The solution is to use the registry instead.
I want to use different icons for my setup.exe (top-leftmost corner of the installer window) and Add/Remove Programs. In my Bundle.wxs, I used <Bundle ... IconSourceFile='path\to\product1.ico'> but when I set the value there it is applying to both places as described in its documentation. So I tried this in my Product.wxs <Icon Id="ProductIcon" SourceFile="path\to\product2.ico"/> <Property Id='ARPPRODUCTICON' Value='ProductIcon'/> in an attempt to override the declaration in Bundle, but it still shows the first icon in Add/Remove programs. Any help? Thanks!
I faced the same problem. The solution is to change Logo attribute of custom BA main window.
The short question is: How to use util:CloseApplication element in a Bundle.wxs file?
Details:
I made it work as desired in Product.wxs file with following syntax but it's not working/executing when used in Bundle file
<util:CloseApplication Id="closePowerPoint"
Target="POWERPNT.EXE"
Description="Please close PowerPoint application to proceed."
PromptToContinue="yes"
></util:CloseApplication>
Am I missing something in bundle file to make it work, or it's not possible/recommended to use it that way?
Any idea or solution would be highly appreciated.
CloseApplication represents a custom action so can therefore be used only in an MSI package.
I've used the dark.exe to create a WXS file from my 'old' Visual Studio 2010 msi file.
When I open the created WXS file, It has binary references on the top of the file that I can't explain. Can somebody tell me about it? And where can I find some documentation about it?
<Binary Id="InstallUtil" SourceFile="C:\Temp\Binary\InstallUtil" />
<Binary Id="MSVBDPCADLL" SourceFile="C:\Temp\Binary\MSVBDPCADLL" />
<Binary Id="VSDNETCFG" SourceFile="C:\Temp\Binary\VSDNETCFG" />
<Binary Id="DefBannerBitmap" SourceFile="C:\Temp\Binary\DefBannerBitmap" />
<Binary Id="UpFldrBtn" SourceFile="C:\Temp\Binary\UpFldrBtn" />
<Binary Id="NewFldrBtn" SourceFile="C:\Temp\Binary\NewFldrBtn" />
The top three are giving me the most questions because I don't where there for and what they do.
Short answer - these files are used in ui dialogs, custom actions, all places where some files are applicable to the functionality of the setup itself, but the product it installs.
In your case, the first three are DLLs used by Visual Studio Setup Projects to perform custom actions - MSI extensibility blocks. The last three are the icons used in UI dialogs later in code.
To get the files themselves, you should use export binaries parameter for Dark.exe.
Now, your options here depend on what you want to achieve. If your task is just upgrade your setup to VS2012, quick and dirty, then use the exported files as they were, it should work.
If, however, you want to do it clean and nice, or you should update your setup with new features, then you will have to rewrite these.
For UI: if your project does not contain custom UI, I suggest switching to WIX UI library - nice and built-in. If you have custom UI, you may extend it, but it is a lot more work. There are visual UI editors for WIX.
For custom actions: custom action is something you use when MSI/WIX abilities do not give you enough. To upgrade these, you should look where these first three binaries are used, and how they are called. Usually, the meaning of custom action may be devised from its name. Then, you have to replace these custom actions with your own (or ready-made by others or WIX team) that do the same. Then you may remove the unused binaries.
I have the following CustomAction in my project:
<CustomAction Id="InstallDriver"
Return="check"
Execute="deferred"
Impersonate="no"
FileKey="FileDriverInst"
ExeCommand="-install" />
<InstallExecuteSequence>
<Custom Action="InstallDriver" Before="InstallServices" />
</InstallExecuteSequence>
The program that installs the driver produces useful return codes, for example if the installation failed because the system needs to be restarted following a previous driver uninstall.
Currently if anything other than success is returned, I get a dialog saying 'A program run as part of the setup did not finish as expected.' and the installation fails. This is not optimal.
How can I get and handle return codes?
Windows Installer doesn't support handling custom action return values.
For an EXE custom action a non-zero return value is interpreted as an error and the installation stops. Only a win32 DLL or VBScript custom action can change the installation behavior through its return code, but it's still very limited.
If you want to reboot the machine after install, you can set the REBOOT property.
Added as an "answer" by request:
Your whole design is not optimal. It's out of process to Windows Installer and isn't declarative. There are better patterns for installing drivers.
That's simply the way MSI handles EXE calls. You'd have to write your own custom actions to wrap the EXE call and then interpret the failure reason. To me this just adds yet another failure point.
You can't get a return code from a CustomAction, but in a round about way you can set what that return code would be on a property. That might as well be the same thing as getting the return code.
You have to get it within the script/dll your custom action is performing. Otherwise, the return code only shows up in the log.
For example, if you have property like
<Property="MyCode" Secure="yes">
Then within VBScript (or Jscript) you can get the value of that property like this:
VBScript
Session.Property("MyCode")
Initially, it is null. You can set it in VBScript like this:
If someCondition = 4 Then
Session.Property("MyCode") = "4" // For a return code of 4
End If
Once back in your WiX .wxs file, if you look at the value of your property, it is now 4. You could even use it in CDATA tags.
For example, only spawn a dialog if MyCode is equal to 4.
<Publish Dialog="SpawnDialog" ...><![CDATA[ MyCode = 4 ]]></Publish>