I am trying to call a msi inside wix bootstrapper program.It is working properly at the time of installation.And selected features are installed properly.But after installation i am trying to modify the installed features.In the control panel there is change button.But when i click it then it is showing a dialog with Repair, uninstall, cancel buttons.There is no modify button for modifying the features of installer.
Please specify the solution if any.
code inside Bootstrappertheme.wxl is
<!-- Modify dialog -->
<String Id="ModifyHeader">Modify Setup</String>
<String Id="ModifyNotice">[WixBundleName] is already installed on this machine. If it's not working correctly, you may repair it. You may also uninstall it.</String>
<String Id="ModifyRepairButton">&Repair</String>
<String Id="ModifyUninstallButton">&Uninstall</String>
<String Id="ModifyCloseButton">&Cancel</String>
The wix standard bootsrapper application does not currently support msi feature selection. Currently, the only way to get it is to create a custom bootstrapper application. People have asked about this on the WiX mailing list multiple times. Rob Mensching is the project leader, and Bob Arnson currently manages the 3.x branch.
This guide: Writing Your Own .Net-based Installer with WiX is the best resource I know about for building one in WPF. The actual WiX source code is very helpful as well. It's a very big task though.
I don't have a sample project to share with you, but the blog post I mentioned above does have a section "HANDLING CURRENT & FUTURE STATE" which describes how to do this. I think it really is a terrific resource.
Also, see this question: Custom WiX Burn bootstrapper user interface?
Burn GUI
Burn GUI is very different from MSI-GUI. Here is an older, similar answer
Please also see comments in these answers:
On customized GUI
Changing text color to Wix dialogs
Custom WiX Managed Bootstrapper Application
MSI File
What dialog set are you using for the MSI files? Have you tried enabling the advanced dialog set? I haven't tried it yet: http://wixtoolset.org/documentation/manual/v3/wixui/dialog_reference/wixui_advanced.html
WixUI Dialogs:
http://wixtoolset.org/documentation/manual/v3/wixui/dialog_reference/wixui_dialogs.html
Tutorial:
http://wix.tramontana.co.hu/tutorial/user-interface/ui-wizardry
It might be possible to use Orca (http://support.microsoft.com/kb/255905) to edit the MSI and resave it so that it, without special configuration in wix, automatically has the Modify option in Programs and Features. When creating an MSI from scratch (using InstallShield for example), the user can specify which options are available. There should be a way to edit the file to accomplish the same thing.
When you open up the "Change" feature from the Programs and Features menu, it reruns a cached version of the MSI installer in maintenance mode. Regardless of what program is bootstrapping the MSI (wix vs InstallShield), the MSI is the only thing that Windows knows about. If it is not configured to have a Modify option, it won't have it.
Related
If you add ActionData to the Subscribe event in Edit Control on Wix,
the line is written and erased. I want the ActionData log to continue to be written as a scroll.
Burn: WiX Burn allows you to write your own GUI to run your installer. You should be able to implement whatever you want in terms of GUI if you go down that path. However: installers run quicker and quicker as IO becomes better, are you sure this is time well spent? I'd say just use logging and be done with it? See my comments above for your question.
Burn Bootstrapper Appliation: There are not that many samples I know about for Custom WiX Burn Bootstrapper applications. Here are two:
Write your own WiX Burn setup GUI application (advanced)
https://github.com/rstropek/Samples/tree/master/WiXSamples/CustomBurnUI
Documentation: For documentation go online, or better yet open WiX.chm and locate section "Building Installation Package Bundles".
Here are two past answers that I would suggest you at least skim:
Ways to customize your WiX GUI (do read this one for overall understanding of MSI GUI)
Custom GUI - WiX Burn, Installshield Suite Project, Advanced Installer - their options
The Implementation of a custom GUI for an MSI depends on the core MSI API function MsiSetExternalUI function. It allows what Burn is doing - making a custom GUI. Throwing in an SDK sample too:
MSI SDK Sample: Some details on the MsiSetExternalUI function (serverfault answer). Concrete code sample to handle Windows Installer messages: https://learn.microsoft.com/en-us/windows/desktop/Msi/handling-progress-messages-using-msisetexternalui. This is MSI API calls direct - nothing to do with Burn as such, Burn makes use of these calls.
Links: Link overload - as usual - but here is an example of a custom Burn theme - as opposed to a custom bootstrapper application. This changes the look of the standard Burn bundle.
https://github.com/frederiksen/Classic-WiX-Burn-Theme
SQL Server named instance with Visual Studio 2017 Installer project (just for inclusion)
Native Windows Installer UI doesn't support this. You would need to create a custom UI handler to display it the way you want.
I'm a bit confused about how wix burn and the main installer are expected to interact with each other. I'm new to wix and windows installer technology in general.
Based on the examples I've seen I was under the impression the burn application would install prereqs then switch to the main installer. However I've seen comments from searches that when using the burn application the main installer becomes secondary and the burn UI should be used instead. This is reinforced by the behavior of the burn application. What I mean is the burn application has it's own license agreement, ARP entry, hides the main installer by default, and has it's own change/repair entry.
This has me confused because the burn application is lacking a lot of functionality the main installer has through MSI. Some functionality I would consider essential such as feature selection, directory selection, and changing features. But this is absent from the burn application.
I feel if I used the burn application as the primary I'd have to recreate the UI, while if I used the main installer for prereqs (if possible) I'd have to recreate the functionality burn provides. Neither approach is desired, so I am wondering how other users of wix handle large projects. Is it standard to write your own custom burn UI? Any help that might clear up this confusion would be greatly appreciated.
Common practice would be to use the Wix bootstrapper (burn) specifically for installing software that is necessary to run your main application, first and automatically.
You would indeed use the main MSI produced by Wix to install your main application. You would use one of the UI (dialog set) sequences already available in Wix. The dialog set will be applicable only for the main MSI, because again, the bootstrapper's main responsibility is to install pre-requisite software for your application to be able to run.
The whole installation process involving your application MSI in conjunction with the bootstrapper executable would be as follows:
Pre-installation
You would build your application MSI.
You would make sure your MSI is specified in your bootstrapper .wxs file.
You would build a Wix bootstrapper executable file which, if correctly set, would
include your appplication MSI.
Installation
You simply run the bootstrapper executable file.
All pre-requisite software will be installed first.
Your main application MSI will now be executed. The user will now be able to set e.q. the installation directory of your application through the dialog sequence of your main MSI (including the other points you've mentioned, if the correct dialog sequence set has been selected before building).
Hope this helps to clear out things a little bit!
What is the best way to make a silent installer (or unattended) for a program that was already created and has a msi installer?
At work I'm told to create an installer that is automated and does all the interaction with the user automatically so that the user essentially just hits one button and it runs through the msi installer of the program that was already developed. Also I have to make it replace a couple files in the directory.
Is it possible to make a installer automate another installer?
Can it be done using WIX in visual studios or NSIS?
Do I need to be able to pull the already developed installer into Visual Studios? If so how?
Bonus- I would like to be able to design the UI so I can place the company logo on it.
I'm a beginner in this field and learn best from walkthrough's or tutorials.
1) Yes - a bootstrapper is what you are looking for. Burn.exe comes with WiX, more information here
2) Yes to using WiX I know nothing about NSIS.
3) If you have nothing you need to change in the MSI then you could just use WiX to create the bootstrapper that would install your existing MSI.
Bonus) WiX lets you fully edit the install dialogs including logos, licenses, etc. More information here.
Extra thoughts: silent installation is part of MSI; your current installer can be installed silently by executing
msiexec /i <your msi> /quiet
in a command prompt, the command prompt may need admin privileges.
If you need to make changes to the existing msi look at using Dark.exe again a component of WiX that will decompose your existing MSI file into .wxs files. This post may also prove informative on moving to WiX.
Are there are any templates or guidelines for creating a Windows Installer XML (WiX) project for deploying a Petrel plugin?
Are there any reasons for WiX not having been selected as the natural successor to the old *.vdproj/MSI recommendation?
Has anyone tried WiX for Petrel plugins? I'm interested in exchanging ideas and experiences. I'm new to WiX, and find it difficult to get started.
(Off topic: the "new" PIP paradigm is lean and simple, but is a bad fit for enterprise use, where clients expect to be able to repackage an MSI in order to facilitate mass deployment through e.g. group policies. I'll post another question on this.)
MSI deployment is still supported in Ocean/Petrel regardless of the way of MSIs generation (and WiX is just another way to generate them).
In Ocean/Petrel 2012.1 you need to define custom action calling command-line tool PluginManager.exe with /install and /uninstall switch during the installation and uninstallation steps respectively. Custom actions are defined using <CustomAction> tags in WiX. There are two tricks you need to keep in mind when calling PluginManager.exe from MSI custom actions:
you need to supply your MSI installer ID (usually GUID) in /installerId:your_installer_id command-line switch during the installation. This will enable automatic MSI uninstallation of your plug-ins when Petrel is uninstalled
you need to run PluginManager.exe with /runFromInstaller switch during the uninstallation. By doing this you let PluginManager know that you run it from MSI installer, and so there is no need to run MSI uninstallation once more
You can find these and other tips and tricks, with full PluginManager.exe command line speicifications in the Plug-in Identity and Deployment White Paper in Ocean.chm (section "How to use PluginManager.exe in MSI installer").
Important information with Petrel 2013:
We have plugins that can be installed or uninstalled using MSI, created with Wix. When installing a PIP with PluginManager.exe without using the argument /installerId:<msi_installer_id> uninstalling the plugin using the Petrel physically deletes all your files, but create an inconsistency in windows uninstaller plugin. If we use the argument /installerId:<msi_installer_id> uninstalling the plugin using the Petrel occurs only logical deleting the plugin, keeping it physically in their original directory. This allows it to be installed subsequently also by Petrel. In the latter case, there is no inconsistency, because the windows uninstall the plugin and be able to delete all your files.
The problem is that uninstalling the plugin using the Petrel 2013 is not calling its MSI uninstaller. It should not be? This looks like a bug.
I have an existing large WiX install that has already been released. I need to create a small install for just a couple of files that have changed. I have created a patch (.MSP file) in WiX for these few files using the "PatchCreation" element. When the patch is run, it presents the user with a "Reinstall/Repair/Remove" dialog. If the user selects repair, the patch does exactly what it is supposed to. My problem here is that I don't want the patch to say "repair," or to give the user these options. I just want it to install over the few files I have, more or less like a regular install. What can I do to fix this?
MSI implements patches as repairs. In WiX v3.5, the WixUI dialog library has dialogs that are displayed when installing patches.
I have found a more flexible way to work around this, thanks to some help I found here. If you start MSIExec with command-line options (for example, "msiexec /p [patch file] REINSTALL=ALL REINSTALLMODE=omus"), you can get the install to start up without the "Repair" option coming up. You can also use the IExpress tool (which is shipped with Windows, and can be brought up in a command-prompt) to create a wrapper/bootstrapper that will start the MSP file from MSIExec.
Thanks very much to the answers I received. I would not have figured this out without your help.
I partially agree with Bob. Patches in WiX are applied through a repair, but Windows Installer does support a standalone patch installation. Other setup authoring tools can create them.
Regarding the WiX patch, I recommend using a custom bootstrapper which applies the patch automatically.