I had included msi in Bootstrapper project using MSiPackage under chain element.
I had observed Wix calculating required space using package size and Installed size, also observed Installed Size value is summation of all files size.
If I'm installing all the features present in msi then the summation of package Size and installed size was displaying in Control Panel as required space, which is correct.
But in my case, I'm not installing all the features. Even though only few features are installing, wix displaying entire package size and installed size in Control Panel.
Either all features were installed or only few features were installed, same space was displayed in Control Panel.
I'm using 3.11 version of wix and Visual Studio 2017.
I want to know exactly how wix calculating the required space to install and also, is wix calculating the space correctly?
Thanks in advance!
Related
I am currently using WiX Toolset to build my installer. This tool is very nice but recently I encountered a problem. When I installed my program with .exe, then upgrade it with .msi, there is a double-entry in Add/Remove Program. Is there anyway to prevent the installer add double entry? Thanks!
It's not clear from your post if you have followed the rules for a major upgrade, such as use the same UpgradeCode, new ProductCode and PackageCode, increment ProductVersion in the first three fields, have upgrade logic in place in the MSI (such as major upgrade element). You'd need to supply your WiX source for these in the old and upgrade builds to see the differences. A verbose log would also help, installing the MSI with a command line that includes /l*vx [path to log file]
If those rules have been followed, the main reason for failure to upgrade is the one was per user and the other is per machine (or vice versa). One context will not upgrade the other. If this is the case the log will have an entry somewhere with FindRelatedProducts referring to an installed product in another context.
All this also assumes that the original install you did was MSI-based underneath the exe. If it was not, and it was some other install software that is not using an MSI file then there is no such thing as an automatic upgrade. You'd need to find some none-MSI way to uninstall the older product. A typical way is to find the UninstallString in the registry for that product and run it. Depending on the software used, that command can be parsed to add a silent option.
I have a bootstrapper that only wraps one MSI. I might prefer to give the MSI to customers who I know have already run the bootstrapper and have the prerequisites installed. But running the MSI leaves the original entry in Control Panel alongside the new one, even though the UpgradeCode code is the same for Bundle and Product.
I understand there are some issues here - the bootstrapper is not the MSI, and in fact may contain more than one MSI. So I imagine this is actually expected behavior.
Is what I want to do just considered a bad idea? Should customers who install with a bootstrapper always upgrade with a bootstrapper?
If you don't upgrade a bundle with another bundle, the old bundle's registration (more than just an ARP entry) and package cache is left behind. So yes, standard behavior is to upgrade with a newer bundle. If you are just trying to save download bandwidth, you can distribute an uncompressed bundle (just the bundle .exe with no embedded packages); only the necessary payloads will be downloaded and you won't waste bandwidth downloading prerequisites that are already installed.
I have a custom installer based on WiX technology which is install several .vsix packages into Visual Studio.
If this packages are already installed, the installer offers to remove them. After the removal process is completed, the installer exits.
It's normal behaviour, but I need to offer the user re-install this packages (optionally) before exit. I mean optional mode to uninstall the previous version and install the new one (or the same) with a single run of the installer.
How to implement this in WiX ?
I suspect your custom installer could be made a little smarter. There are plenty of APIs (such as MsiQueryProductState) that will tell you if that exact ProductCode is installed, and ways to get the version (MsiGetProductInfo). My guess is that your custom installer is just firing off all the MSI installs without checking if they are already installed, hence the Remove prompts.
Your general plan should be to have some data available to your custom installer that it can use to find out what's already installed and what the versions are, and then compare these with what you are about to install. Use those APIs. If the product is already installed then skip the install. If you have a newer version (that you built with the WiX MajorUpgrade element) then just install it because it will replace the existing older one.
There's nothing I can think of in WiX that would automatically reinstall a product that your custom installer caused removal of by re-installing it and prompting the user to remove it, if that's what's going on.
We are deploying our software via a .msi package that is created using Wix and the functionality/software deployed requires a certain (>=) patch level of Visual Studio (at this particular stage everything with the latest, cumulative update 3 / KB2662296 is our target version).
Is there any (Wix built-in) way to check whether VS(2010) has a certain patch level?
If it's not among these predefined properties, you'll have to perform registry search to find it out, save to the property and use it in your conditions.
I have created a wix installer project which is working fine. It installs my application on system easily. whenever if there is any change in any file or service, i uninstall msi from controk panel and installs new msi on system.
But whenever i install new msi, application's all setting change after new installation, that doesn't sound good. For sort out this, i am using Upgrade code in Product.wxs file. But when i install new msi after build, but is shows given error:
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel
So, i want to update windows application package whenever there is any change in files and with same Product id. I just want to update installed msi, dont want to remove that.
You cannot use the same ProductId to do upgrades, you need to change it. The best way is to set ProductId="*" and this will change it for every build. You will also need to increase the version number and this best done by using the main exe assembly version number. See http://wix.sourceforge.net/manual-wix3/major_upgrade.htm for more info.
You can use the same ProductCode to update an installed MSI. Basically you increment the ProductVersion, rebuild the MSI (with new PackageCode) and do a minor update with a command line such as:
msiexec /i <path to new msi> REINSTALL=ALL REINSTALLMODE=vomus.
In my experience this not commonly used because if you're going to rebuild the MSI you may as well upgrade with a major upgrade.
If all you want are updates to a few files and you're not ready to ship a complete MSI file, then that's what patches are for. Rebuild the MSI as above, then build a patch - the patch is the delta between the two MSI files, see docs for MsiMsp.exe.