I've created a custom managed bootstrapper in WPF using Wix 3.7. I used an existing XAML themes library to create the bootstrapper UI. I added the same themes library as a payload in the bootstrapper wxs file.
The problem is themes are getting applied during the design time but on running the bootstrapper's .exe file the themes are not getting applied.
Can some one tell me why it is happening?
You'll want to follow up with the implementation of the library to understand how the themes are loaded. Often, those types of libraries make assumptions that the files will be relative to the executable. Because the Burn engine is a native host those assumptions are incorrect. Instead, the library needs to load the themes relative to the current executing assembly.
Related
I am designing a multilanguage application in C#. The project structure is shown here:
The form frmLogin use 3 resource files to get some controls text and labels frmLogin.*.resx which I would like to add in the wix project file.
The language is selected at runtime by a number of radio buttons.
I DO NOT want to have a multilanguage Wix installer, just a single installer which installs the required culture-elated dlls in the installation directory
I looked here Add resource files in wix installer but it did not worked in my project
There is something obviously wrong in the wix project file since it does not create language directorys like this:
in the installation directory ...
I am sorry if I am missing something trivial but I am starting now with wix which looks very promising indeed but I am just starting now
many thanks
I'm using WiX toolset 3.6 to build a simple MSI installer, but I'd like to customize to look and feel of the installer UI.
I've found plenty of resources on customizing the images, replacing the strings, setting the font for those strings, etc., but I did not find anything on embedding a custom font and using it as the font family (over existing system fonts).
How can this be done?
MSI UI doesn't support loading fonts. You can use a bootstrapper application in a WiX Burn bundle and do anything the OS supports.
We have a product similar to Microsoft Office. Several different applications with a lot of shared libraries. We’re trying to refactor the deployment process of this product as currently we’re using several individual MSI packages to install each application independently. While this is working, we would like to use the WiX bootstrapper to bundle these MSI files and create just one setup application. Currently all shared libraries are included in each MSI package, which takes a lot of space.
We have basically two options to achieve this:
Create one WiX setup (MSI) project; include all products as individual
Features. In this case handling the shared libraries is pretty
straight forward. But the structure of the project is getting too big
in my opinion.
Create several MSI packages. Each with just one
product and bundle them to the bootstrapper. In my opinion, this
approach is more flexible and more clearly arranged in terms of files
and components. However how do shared libraries work here? They
should not be included in each and every MSI file.
Which approach is preferred in a WiX bootstrapper project?
One big MSI with many features is too hard to support.
It's easy to share components between MSIs. The shared components must have identical GUIDs and component key paths. See details.
To easily achieve this goal create a WiX Library project for all shared components (each component or component group in its own fragment). Then include the library into all WiX Package projects and reference its components (or component groups) in WiX Package projects.
You can group shared components into several MSIs, then create one or more bootstrappers for your applications.
A couple key things to know:
MsiPackages can be configured so when the bootstrapper installs an MSI, it shows or doesn't show the MsiPackage in "Programs and Features" (ARP) list.
An MSI may or may have its own UI. In any case, you can suppress it in the MsiPackage element. If your really, really need to ask users something during installation, you can ask in a custome bootstrapper application and probably pass it to the MSI as an MsiProperty.
So, I suggest an MSI for each application and each group of shared components. And, one or more bootstrappers for one or application MSIs and the shared MSIs that they need. If you create a custom bootstrapper application UI (C++ or .NET), like Visual Studio and WiX itself do, your users can selectively install/uninstall your various applications using one bootstrapper.
For our product, to develop an Installer we are using WIX 3.6.
In installation sequence and as part of requiremet we need to configure some changes.This we have implemented separatley in winforms ( (treeview) and referred that exe in installation sequence. The exe is openeing perfrectly but opening in a separate window. We want to open in WIX UI itself not as a separate window.
Please provide inputs to achieve this. Thanks in advance.
It is not possible to launch the executable from inside the installation and integrate with the UI displayed by the package. Instead, you can launch an executable and have it register as an External UI Handler. From there you can parent the package UI to your external executable's UI.
I have a Wix 3.6 managed bootstrapper in which the user can select individual packages to download and install. I want to show the download size of each package. How can I access the file size of each packages in the Bundle?
I guess this information is available somewhere in the Wix framework (because the file hashes are used to validate the downloaded files), but I did not find it.
I have an idea for a workaround, but it would be more implementation for me:
Have a wxs file generated programmatically that contains Variable elements containing the file size of the packages. Those variables would be read by the bootstrapper.
When your bundle is created, a BootstrapperApplicationData.xml is added to the bundle. That XML file contains a lot of metadata about the bundle and contained packages. Your bootstrapper application code can load this file by looking in the same direcotry as your bootstrapper application dll lives.
I did not found how by using the burn API, but I implemented my own workaround:
If the local file is present
query the file system
else
query the web server