I have x86 and x64 installers of a product building from the same wix source. What I'm looking at now is handling situations where a customer has installed the x86 software and attempts a Major Upgrade with x64 media, and vice versa. I don't want to allow either of those to happen.
I had originally imagined looking for the presence of a HKLM/SOFTWARE registry key we set, but that won't work with x64 installed and an x86 upgrade - the latter won't be able to see it from the WOW64'd registry.
My current idea is to use two different UpgradeCodes for x86 and x64, and add some <Upgrade> trickery to have it abort if the other one is installed. Is this the best way to go out about it, or is there something better?
Two UpgradeCodes is the right thing if you are splitting into two incompatible product lines, which seems to be the case because you want them mutually exclusive. In that case you could use an Upgrade search to detect the incompatible x86, except that FindRelatedProducts runs fairly late in the install after ALLUSERS has been chosen, maybe some dialogs shown, and has the (being picky) issue that you can't cross detect per user and per machine. So I don't like that solution.
I'd find an x86 component in the x86 product and search for it using an AppSearch for that component guid. That happens really early and can most likely be used in a launch condition because AppSearch is before LaunchConditions. Then the user doesn't see anything at all except a message saying they can't install this because that other product is installed. Or maybe a registry item or something that can be used as a launch condition to prevent the install at launch condition time.
Related
Disclaimer: I've still never gotten beyond the most basic WiX tutorial, because every time I try to understand the concepts, my head starts spinning.
I've been reading Is it feasible/sensible to wrap an InnoSetup installer inside an MSI for easier distribution via AD? :
There is a tool (look for exemsi MSI wrapper) today that can wrap a script/exe based installer, like InnoSetup, and provide install, upgrade and uninstall.
From my experience, that's what users expect: Can install product, newer setups can upgrade it, uninstalling will remove product.
Yet quite a few answers on that question state that only a "true" MSI can reliably provide "all"(?) required(?) features.
So, given that what I always thought an installer was supposed to do is:
Install product with as little hassle as possible
Allow repairing a product (possibly by simply running the setup again)
Allow upgrading of product via a newer setup
eventually uninstall the product, leaving as little trace as possible.
The question is, given that it is proven that, given the right tool, the points above are possible by simply wrapping an exe in an MSI, what additional advantages do "real" MSI packages offer?
To be clear here: An MSI package does (seem to) offer additional benefits for enterprise / AD / GPO distribution, that you don't have if you have a bare .exe installer - I don't question that. What I'm interested in is what - actually used - features are only possible through a "real" MSI package?
MSI supports installing additional features on demand. A shortcut (.lnk) created by MSI contains special metadata recognized by Windows and can automatically repair and/or install missing features.
Another advantage is that non-administrators can install patches without UAC elevation if the package is signed.
Some disadvantages of MSI are:
Cannot create a single .msi for 32-bit and 64-bit targets.
Single user/non-elevated installers can be problematic because the support for this has changed over time and new MSI properties have been added.
Depending on your minimum supported Windows version you might have several major versions of MSI to test/deal with.
Bloats your system drive by storing the full .msi in %windir%\Installer on recent versions of Windows.
Bloats the registry by storing the path and other information about every single file it installs.
Installation or removal operations are by Feature (of a Product). This is not as relevant as it used to be because of the trend toward smaller installers with fewer questions being asked of users. For large installers, for example Visual Studio and SQL Server, questions are asked via bootstrappers--the opposite of what you are considering.
Installation, repair and removal are by Component (across all Product and Version). Reference counting is under the control of Windows Installer and is less likely to become corrupted than the pre-Windows Installer technique. Shared components are now less common because of different application technologies such as .NET and registration-free COM. Large systems might share components but again they might be divided into separate installers so that no Component is needed by more than one Product.
Whether these are advantages depends on the needs of your installation architecture.
MSI supports advertisement of the available application without installing them (more details in this MSDN post). It's handy in a corporate environment as it allows deploying only the most essential applications and 1) saves physical space on user machines; 2) reduce expenses for apps with per-user licensing (only those who really need that app will actually install it and activate the license).
We are using the WIX Toolset among other things to automate a long installation process. A big part of this is installing lots of prerequisites that change based on what version of the product the customer wants to install.
e.g. there is a filter pack (.msi file) involved in the installation that only needs to be installed with a certain type of the product, so it is impossible to simple chain it into a bundle because we cannot know in advance which version the customer chooses.
Is there any way to solve this problem without having to create 4 different installers or installing all prerequisites regardless of version?
Thanks in advance.
The easiest and most maintainable (imo) method for implementing this is to use a burn bootstrapper and have a separate msi install for each version of the product the user could install.
The burn boostrapper would also contain all the prerequisite packages needed but only install the ones required by the specific version the user chooses to install.
You say you can't include the filter pack in the chain because you don't know until runtime whether or not the customer wants it but that's the whole point of the bootstrapper. Your bootstrapper should gather the information at runtime and set variables accordingly. Using the InstallCondition on the MsiPackage element you can determine whether or not you need to install the msi or not.
The bootstrapper process is to run Detect, do the UI, Plan, Execute. During Plan you will figure out which packages will be run and installed during the installation. The bootstrapper application has the authority to set any package to install or uninstall, overriding whatever the engine decides to do.
You could also include all the msi version stuff in one MSI and control it via feature groups which would allow you to use one MSI fo all the versions of your product but this can get bloated and complicated with multiple 'duplicated' components from different versions of your product so I think this would become a maintainability hell later on.
You can add a custom dialog which has checkboxes where the user can choose what to install.
These checkboxes set a variable to 0 or 1. You can use these variables in the installcondition.
I believe you can even conditionally show checkboxes(say 2 off the 5 are already installed, you would not want to give the user the option to install the already installed 2)
We have two WiX installers that use our own BA. One installer gets all the packages from the web, while the other gets all the packages from the exe. We call them "Web" and "Full" installers.
We have a case where a user might install one package from the web installer and a different package form the full installer. It probably won't happen often but it could happen. When the user does this, we have two entries in the Add/Remove programs control panel. Since we didn't name the installers differently, it looks like the installer is installed twice.
My question is, if the only difference between two installers created with WiX is the way the packages were acquired, shouldn't it just appear once in Add/Remove programs? Do I need to set a code somewhere to say it is the same installer?
I guess we could just name them differently so that a "Web" and a "Full" installer appeared in Add/Remove Programs, but when you run either one, both packages show up for uninstallation because both installers know about them. It's not like the web installer only shows the package that was installed through it and the full the package that was installed through it.
Any comments are appreciated.
In a version upgrade scenario, using the same UpgradeCode for both <Bundle...> packages is enough to indicate both installers are the same product. For example, if you first install package V1.0 and later install package V1.1 (where both packages use the same upgrade code) Package V1.1 replaces Package V1.0 in Add/Remove Programs.
Unfortunately the burn engine does not support same version upgrades. If you have different packages with the same upgrade code and the same version, both packages will appear in Add/Remove Programs. For more information on burn not supporting same version upgrades see: http://wixtoolset.org/issues/3746/.
Installing two different packages with the same upgrade code and version is well behaved. For example, if you install both packages and subsequently remove one of them, the resources in the first package remain installed, even though the same resources are also in the second package.
Installing two different packages with the same upgrade code and version, then later installing a third package with the same upgrade code but a higher version is also well behaved. The third package replaces the first two packages!
Your suggestion of varying the name of the packages to differentiate them in Add/Remove Programs sounds the most pragmatic way forward. Having two entries does not appear to compromise the installation state, and upgrades appear to be handled without issues.
Having an issue with WIX installer upgrade. Previously we had 2 version of installers 1 for per-machine and another for per-user.
Currently we have developed a dual mode MSI.
The dual mode MSI upgrades the PerUser version (on PC 1) of previous installer when install for yourself option is selected but when install for all (on PC 2 ) is selected it install a new product
Is it some wrong that we are doing or is have to set some properties. We are using WIX.
Please help
Per-user installs allow the installation of the same product multiple times for different users - and in different versions too. This makes upgrades and patches rather difficult to deal with, and I dislike this per-user concept altogether. I prefer to set the installer per-machine as standard. I don't feel that much is lost in functionality, but a lot is gained in managability. Though this is not an answer to your question, it is worth pointing out that per-user installs is a flawed concept - at best.
I don't know if it is an option to set your installer per-machine, but I found a way to migrate installs from per-user to per-machine automagically by using Installshield and its custom ISSetAllUsers custom action. The procedure is described here:
windows Installer - uninstalling previous version when the versions differ in installation policy (per-user, per-machine)
Wix does not feature such a custom action as far as I know, but you could write your own custom action using the Win32 API call ::MsiEnumRelatedProducts() as described by Rob Mensching here: how to change from per user to all user installation?
Here is a similar post for reference: How can a perUser installation program deal with a perMachine older version of the program?
Here is a blog describing (further) issues with per-user installs: Understanding “Per-User” or “Per-Machine” context for application Setup packages.
Let me add a couple of further comments:
You can have per-user settings without a per-user install. This is no problem, just have the application set up the userprofile on launch. I prefer to install all resource files and settings per-machine and have the application copy them to each user for first launch initialization. This ensures that user settings are not entangled with your MSI at all.
It is rare to maintain two separate versions of the same product at the same time - hence users are all likely to use the same version of the product. Per-user is just more headache in this perspective.
The upgrade and patching logic involved in per-user installer scenarios beats me - it just doesn't make any sense to me. If there is a per-machine install already, does a per-user install make sense to you? Does this install the application one more time?
If per-user installs are still important, perhaps you can try ClickOnce (if it still works). Quote from Wikipedia: "...ClickOnce-deployed applications are considered 'low impact', in that they are installed per-user, not per-machine. No administrator privileges are required to install one of these applications. Each ClickOnce application is isolated from the others. This means one ClickOnce application is not able to 'break' another.". Per-user installs make more sense if they are hooked up to auto-updating and web-deployment.
If you had two setups before, it might be that you have two upgrade code and need to deal with both for the upgrade to work in all cases?
It has been a long time since I dealt with per-user stuff, but in general you must author your Upgrade table to include both upgrade codes for your setups to detect all flavours of your previous install. The upgrade table allows you to detect any number of prior installs that should be scheduled for uninstall before your new product gets installed.
The FindRelatedProducts MSI action will search all packages on the target machine in order to find any where the Upgrade Code property matches the value specified in the upgrade table.
Make a verbose log file as has been suggested:
msiexec.exe /I "File.msi" /QN /L*V "C:\Temp\msilog.log"
/I = run installation sequence
/L*V "C:\Temp\msilog.log"= verbose logging
/QN = run completely silently
I believe this is occurring because in your installer the default mode is Per-User hence it is not detecting per-machine.
You could use MSIGetProductInfo to find the installed products if the assignmenttype is “1” then you could set the below properties to Product Code of Per-Machine product
WIX_UPGRADE_DETECTED
OLDERVERSIONBEINGUPGRADED
Use a custom action on button click or schedule it after FindRelatedProducts.
This tells the installer of an existing version and installation is handle like an upgrade.
Windows Installer does not upgrade between per user and per machine, or vice versa. If you want this to happen you need to get in front of the install somehow and find out what type is already installed. Trying to do that when the product has been installed for another user (i.e. not the current installing user) is tricky. MsiEnumRelatedProuctsEx can be called a couple of times looking for per machine and per user installs to see what's going on. However there may be issues with you, User A, trying to uninstall a product that was installed per user by User B. If you are the same user it's easier. MsiEnumRelatedProductsEx can be called a couple of times to see if the product is per user or machine (in a launcher maybe) and you can uninstall the product before installing the new upgrade, or at least tell the user to do the uninstall. Anyway, it can be a mess, and the advice to stick with per machine installs is worth taking.
I should also point out that allowing per user AND per machine installs on the same machine is a feature, not a bug.
I created a WiX-based installer back in the WiX 3.5 days. The documentation then was even worse than it is now. To make matters worse, it was my first installer—so I didn't do everything right.
Some background: the installer installed two applications and a driver (each of these were a separate feature consisting of one or more components). One of the applications in question is a vendor-proprietary device configuration application written in VB6. Since it's a VB6 application, it uses the libraries comctl32.ocx and tabctl32.ocx.
The crux of the problem is that I didn't see these two libraries in the %windir%\System32 folder on Windows Vista (and/or Windows XP? I don't remember, it's been years since I first wrote this installer). So I thought I needed to install these two libraries along with all of their requisite COM registry entries. (I ended up installing the COM libraries in my application's folder—as you would for a private assembly, but registered them globally in HKLM.) As much as I read about things when creating the first installer, I never once came across the fact that, as of Windows XP, COM components could be installed side-by-side. (And even so, why didn't I use the MSI tables Clsid, ProgId, etc.—which granted, today, is frowned upon, but it would at least have been more correct than what I did? But I digress; what's done is done in MSI land.) Anyway, when creating the original installer, I used the following WiX markup for creating the COM registry values:
<RegistryValue ... Action="write" />
I also should mention that at the time, I had not come across any sort of 'Component Rules 101' kind of documentation as I have this time around. So, this MSI does not follow the component rules. The MSI contained one component for each COM library and its associated registry values with the COM library being the KeyPath of its component.
The question is, if the registry keys/values existed prior to my original MSI running and installing the first version of my product, will uninstallation cause these keys/values to be removed from the system? (I assume these keys/values were created during Windows setup—so are they already reference counted?) I don't want to possibly break other applications on a users' system that relies on those libraries.
If the answer to the above is yes, then my current plan to rectify the situation is:
Author a new MSI as a <MajorUpgrade />—afterall, I am performing an upgrade.
Provide the COM registry entries that were in the original installer for the comctl32.ocx and tabctl32.ocx COM libraries—I'm guessing that I would need to do this with a CA (or multiple CA's) so that they don't get removed again on the next upgrade. I see one of two ways of accomplishing this:
Directly create the registry entries taking care to ensure the values match those of a fresh windows installation (appropriate to the version of OS on which the installer is executing)
Dynamically add the registry entries to be created to the MSI Registry table (which if I understand correctly, isn't tracked by windows installer in terms of uninstallation?)
If previously existing registry keys overwritten by MSI are removed on uninstallation, then:
Is my proposed solution acceptable?
Which of the two options for replacing the removed registry entries is best?
If neither of those two options are acceptable, does anyone have any other suggestions on how I might rectify the situation so as not to break other applications that (may) rely on the libraries in question?
It was a long read but I think this is what you are looking for:
ICE09
To quote the beer commercials.... I don't always install files in the SystemFolder but when I do, I make them permanent.
First, thanks to Christopher Painter above for responding to my question; though, it's not really an answer in the sense that I'm looking for—fixing an existing installer that's "out in the wild". Though, in his last comment about a minor upgrade, that might work for some people.
Next, thanks to Aaron Stebner who responded to my e-mail requesting guidance on this same issue. His advice is to author a MSI component which has no ID. By authoring such a component into a MSI, the component is not tracked by MSI; essentially, it becomes a permanent, uninstallable component. This might work in this situation, if it were completely necessary.
However, after doing some research, I believe that there isn't much risk to damaging a user's system by removing the registry entries I outlined above.
I loaded a fresh copy of Windows XP SP3 and Windows Vista SP1 into a virtual machine. Out of the box, neither of these versions of Windows have the COM components in question registered in anyway in the Windows registry. This makes sense, since from Windows XP onward, there has been registry-free COM registration. This also continues to be the case for Windows 8.1—again, this was expected.
The worst that could happen if these registry keys are uninstalled is that some other older piece of software on a machine that relied on such registry entries could end up broken (e.g. this software is from the late-90's to early 2000's era and used a non-MSI installer and/or installed the COM libraries globally—which they shouldn't have done in the first place—just like I shouldn't have done in the first place ;) ). At that point, the user can either re-register the COM libraries using regsvr32.exe or repair/reinstall the application in question. The likelihood of such applications existing are slim to none in this day and age.