Orca clearly showing Custom action type 23 - Nested Installation
Inspecting in Visual Studio shows no custom actions at all...
As part of an update on the MSI I'm working on, one of the tasks is to remove the nested installation, as it is a deprecated method.
I can't seem to find where this SQL2000.msi is coming from
I can't find a way to remove it
Any time I build the MSI the custom actions will be there. It's not good enough to edit the MSI after it has been built, it must be built correctly initially.
What possible ways could the MSI be pulling SQL2000 into the MSI?
I can't seem to find it anywhere on my computer.
You should say what is (or was) being used to build this install because it's not clear where Visual Studio setup projects are involved (your custom action view). To my knowledge, Visual Studio has never generated type 23 custom actions. So if you are using a VS setup project to build this project, then the only place it can come from is a merge module, so it should be in the imported merge modules. It's probably an MSDE merge module.
The screenshot of Orca and the custom actions has the format that shows they are from a merge module - the custom action name and then the merge module package code, so the MSM you're looking for is the one with packagecode starting A95D...
Related
We use InstallShield InstallScript projects to create our installers and are looking for a good way to migrate to the WiX Toolset. As far as I know there is no UpgradeCode (as for MSI) to update from an Installshield InstallScript project to a WiX project.
The only solution I found so far is:
manually save configurations
uninstall the InstallScript installation completely
install the WiX installation
apply the saved configurations
Is there a better way?
Ok after all those comments I think I understand why this is such an issue. Unfortunately I don't think there is a very simple way to do waht you want to do.
I think your method will be the only real way to migrate from this isntallscript setup based installation. There should be some registry entry in HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall that relates to your product. In here there may be a uninstall command which you could read into a Variable from your burn package and pass that value as a property to your msi.
In you MSI you can have 3 custom actions specifically related to upgrading from the installshield product installation. All these tasks should be deferred custom actions so that they can run with administrator elevation. The first task should copy all the configuration settings to a safe place (generally %temp%\ProductConfig\ would be fine). The second part after saving the configuration would run that uninstall command to remove the product, you may need to append /q or something to make it run passively/quietly. Then at the end of the installation you can copy back the configuration files from temp.
Each of the custom actions should run conditionally on whether or not the property you passed in is set to something. I would schedule the copy cofig after InstallInitialize, the uninstall after the copy and the restore before InstallFinalize just to ensure that everything is copied over after the installer puts all the files on the system.
Ideally you would like to get everything to upgrade without the user needing to interact except in a minimal way by clicking next and Install.
I've only dealt with InstallShield enough to know I really don't like it so if someone else knows more and knows of a better way to do it they'll hopefully chime in.
We've used wix to create our installer for some time now, but previously we've relied on our customer installing SQL themselves.
I now want to include SQLLocalDB for our smaller customers as an option in our installer, but I don't know the correct way to implement this.
I've added radio buttons to our product to chose between using SQLLocalDB or an external server but how do I pass this variable to the bundle's InstallCondition for SQLLocalDB. I Tried using the registry in between but the registry is read as soon as the bundle msi is started and not after the first package has been installed.
My first idea when I started implementing this was to install SQLLocalDB, create the database and the tables from a custom action, but I've now realized that isn't possible
So to finalize my questions:
How do I add optional features correctly?
If I want to create the database and create/update the tables, do I have to create yet another msi for this and add it as a third package in the bundle?
I want to make a MSI installation using WiX and EmbeddedGUI. I really want to make it highly modular - ie the main MSI will contain only the basic files (the required ones), and all other features will be split into separate MSI files, which will be downloaded from internet if not present on hard drive and installed only if selected in my EmbeddedGUI.
But I am totally new to WiX, and I can't find a way to actually how to make that modules? MS Office and MS Visual Studio seems to be using this scheme, by using the modules which it downloads over internet and installs them in case of need - something like this:
It seems that Fragments is mostly like "static libraries", not "dynamic libraries" which would be more useful in such a situation. There is also the Chaining mechanism, but I'm not sure I will be able to bundle the features as the same application (only one entry in "Install/Delete" window) because it seems to be calling external MSIs completely separately (more like invoking "separate exes" instead of loading "dynamic libraries").
So, what is the way to go for making a highly modular setup package with WiX?
Use a bundle (chain). The Burn engine, which manages bundles, will show only the bundle in Add/Remove Programs and can download any packages that aren't already present -- for example, using the MsiPackage/#DownloadURL attribute.
I created an MSI which installs a Visual Studio 2012 extension package (VSIX) and a couple of other components. There's no option to select which features get installed ( I don't want to give user the choice). All the features get installed by default. However, when I try to repair the MSI ( either from control panel or from MSI itself), it throws up an error. How do I customize this Repair functionality? If I cannot customize, how do I disable it?
It would help if you said what the error actually was. However, the most likely reason is that you have a custom action that is running again (maybe because of the condition you used on it) and it's failing because it's not checking that it was run before, or it uses a property value that no longer is valid - for example INSTALLDIR is not preserved after the install unless you preserve it somewhere.
I'm still very new to Wix so i'm trying to get my head around how it works. There is a lot to it and its a bit hard to get an understanding of it. If my Wix MSI Contains a bunch of patch files. Can i use a Custom Action with extract the files to a temp location, run a patcher, update the version with the patched file version and then run any other MSI actions?
I'm not really sure how to do this in the XML. I Assume there is some sort of execution sequence
Also if this is possible i need a way to dynamically add the patch files to the MSI during the Build. Can you base this on an output folder?
WiX is far better than installshield and the like, but without seeing your existing .wixproj this is hard to answer directly. You can use custom actions to do all of what you want, but it's not exactly the "WiX way", as that would not be easily reversible for a rollback or uninstall. Dynamically adding files during a build is absolutely possible. I must absolutely direct you to Ramirez' WiX: A Developer's Guide for Windows Installer XML. I got stuck building a complicated installer like this, and this book was invaluable.
What I can easily say is that for the patching portion, you can run exec tasks to run the patcher program and pass the patch files you want to run. You can dump all of these to a temporary directory to do it.