I'm trying to add hyperlink inside of DisallowUpgradeErrorMessage (from here http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html):
<MajorUpgrade AllowDowngrades="no"
DisallowUpgradeErrorMessage='Older version of MWL installed. Please follow https://example.com/uninstall.html'
/>
I already try to create HTML hyperlink inside message, but got error, something like
"invalid character inside of attribute"
I replace <> characters with < and >, but it not work (shown as plain text). Is there any other ways to do this?
The default WiX dialogs do not support hyperlinks in their text so you will have to create your own custom UI rather than relying on the condition elements. You can find an example of how to do this here.
However, for the case you have mentioned you can have WiX automatically uninstall the previous version of your software. In cases such as this I have found the Upgrade element to be more useful than MajorUpgrade, it allows for granular control of conditions and actions. You can view an example of using the Upgrade element as well as forcibly removing existing products here.
Related
I am using Wix installer for an application and one of the scenarios I am trying to handle is changes to a .config file when the application is upgraded.
Essentially, I would want to add an Xml Element within another Xml Element.
For instance, the original .config file that was shipped with application looked like this
<root-element>
<sub-element-1/>
<sub-element-2/>
</root-element>
During app lifetime, it was updated to as below at some point.
<root-element>
<sub-element-0/>
<sub-element-1/>
<sub-element-2/>
</root-element>
For handling this case , where I need to add <sub-element-0/> under <root-element>, I tried this Wxs code.
<util:XmlFile Id="MyConfig"
File="[fileidOfMyConfigFile]"
Action="createElement"
Name="sub-element-0"
ElementPath="root-element"
Sequence="1"/>
The above formulation does add the sub-element-0 under root-element , however as the last item under the root-element.
like so
<root-element>
<sub-element-1/>
<sub-element-2/>
<sub-element-0/>
</root-element>
I couldn't find any resources on adding it as first element as I want it to be.
Any suggestions on how it could be accomplished?
Note: The above is a simplified version of my use case. The reason order is important in my case is due to a limitation on the framework that some elements need to occur before other elements in the .config
I have been asked to add a function to an existing WiX package.
Specifically, I need to run a small c# application and return a single int back to WiX to conditionally control further actions.
I can see from ExePackage help that there is an ExitCode, but this is an enumeration of success, error, scheduleReboot or forceReboot.
I have googled quite a bit and I am wondering if I am missing the point. I can probably implement the C# process internally within WiX to get the user to provide the information I need, but the existing package already has custom ExePackages written in C# with a particular style, so I'd like to stay with that if I can. (The existing packages don't return any needed values)
Can I do this, or do I need to try and operate entirely within WiX?
For reference, one of the existing packages looks like this:
<ExePackage
SourceFile="..."
DisplayName="License Key"
InstallSize="0"
Permanent="yes"
InstallCommand="/ignoreIfLicensed"
RepairCommand="/ignore"
UninstallCommand="/ignore"
/>
The reference to <ExePackage ...> implies you want the condition to operate in a WIX bundle. In this scenario I think your options are limited and you can only map the return value of an ExePackage to global behaviour like forceReboot.
Do you have any <MsiPackage...> references? If you have, you could move the conditional behaviour inside each <MsiPackage...> using a Custom Action to call the exe and set a property. The property can then be used as a condition in each <component...> you want to conditionally install. See Using a WiX custom action to set a property's value for more information on custom actions setting properties.
I am trying to use Wingdings in my Wix installer, specifically the characters at 0xFB and 0xFC. I tried unicode variants of these (✗, ✓), but since Wix/MSI requires a specific codepage, these do not work.
My TextStyle is:<TextStyle Id="Wingdings_Font_Normal" FaceName="Wingdings" Size="8" />
My control is: <Control Id="TestResult_Success" Type="Text" X="140" Y="237" Width="24" Height="24" Text="{\Wingding_Font_Normal}ü">
In my UI, a raw ü is rendered, rather than the Wingdings glyph for that character.
Is there some way to get Wingdings working with Wix/MSI?
EDIT:
After having a peek with Orca inside my compiled MSI, I've found that my TextStyle table is being generated correctly:
And the relevant lines of the control table:
I manually added a new TextStyle and changed the Text to use the new TextStyle, but was unable to get any Winding symbols to appear in my installer.
I don't have a citation to share but I'm 99.9% certain the answer is no. Windows Installer native/internal UI is about 16 years old and limited in numerous ways. To create a better UI experience you'd need to provide an external UI handler using a tool such as WiX Burn. This is how WiX provides it's enhanced UI experience. If you don't mind taking a dependency on .NET 3.0+ (which was included in Windows Vista and beyond by default ) you could go as far as use WPF to do the UI work.
You can do it by doing the following:
Create a new entry in the TextStyle table, like this for example:
After this you can reference to the new TextStyle in the Control Table (column "Text") just like this: {\WixUI_Font_Wingdings}YourAwesomeText
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
In my current assignment I am having a requirement where I need to create custom eventlog during installation and uninstall this custom eventlog during uninstallation.
I am able to create custom eventlog during installation, but I am not able delete it during uninstallation. I could not find any documentation on how to delete the custom eventlog.
Can somebody please let me know is it possible or not? If possible, please guide me on how to achieve it.
I suppose you're trying to achieve this with <util:EventSource /> element. If that's the case, then the component hosting that event source should regulate its install / uninstall behavior.
If a component is scheduled for the installation, the event source will be created. If a component is to be uninstalled, it removes the event source altogether. At least, this is the way most elements work when placing inside the component.
If that's not the case, edit your question to add more details and some code, as I mentioned in the comment above.