It's a WiX MSI installer and each time I uninstall and reinstall it in my virtual machine environment the size reported in Add/Remove Programs gets bigger. It's up to 200MB now when the installed files are only just over 30MB. Any idea how this could happen and what I might be doing wrong?
Edit: Not using any custom actions, and I don't have anything for the uninstall, just assuming that WiX takes care of cleaning up after itself on uninstall, and it seems to. From what I can see, it's the reported size that is incorrect, I can't find any duplicated files or anything.
Can you put your ARP entries ? Also, how do you handle the RemoveOnuninstall attributs in the wix elements?
Do you have CustomActions that write data? Do you erase that data, when uninstalling ...
Fill in the most details as possible.
I found this post, then that will explain what's your situation here, and the link to how the arp sized is calculated or almost ;)
Related
The old version of the setup was created with InstallScope="PerMachine".
The new version is intended to have InstallScope="PerUser"; it also needs to use the same registry keys as the old version creates.
The problem is that whatever values are stored under these registry keys during the upgrade will be overwritten at the end with the initial values stored by the old version. Even deleting these keys manually before the installation will make them reappear (with the wrong values) after the installation process.
I have tried creating a custom action and specifically delete these keys, but the result is the same.
How can I ensure that the old version does not interfere with the installation process of the new version allowing to delete the old Registry Keys and re-create them?
What I found to be working:
Performing a REPAIR immediately after installing the new version will yield the correct results!
Uninstalling the old version manually before installing the new one will not remove the keys, but will allow to overwrite them with the correct values.
You should define what kind of upgrade you are doing, and if it's a major upgrade then where is it sequenced in your major upgrade element, although...
Probably the main issue is that cross context major upgrades aren't supported by Windows Installer, so if you are doing a major upgrade you will end up with both products installed. That's not an upgrade, that's most likely just a collision. So assuming that you want only one of them to be installed at the end of all this, you will need to uninstall the older per-machine installation and then install the per-user. As to why the uninstall of the per-machine product doesn't remove the registry keys, there are many possible reasons, such as they were created by the app not the MSI, or the component was marked permanent, or the component has another client product on the system - a log of the uninstall might show what's going on.
I have to add this as an answer, too long as a comment. I will "evolve" it once you provide more information:
Why do you want to switch to per-user installation? In the MSI world this is not an ideal way to deploy. An application is usable per-user even if installed per machine. With a per-machine install you simply add the ability to write shared settings that should not be overridden by a user. And your application is easier to upgrade, uninstall, patch and manage overall.
Here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):
Having an issue with WIX upgrade
Understanding “Per-User” or “Per-Machine” context for application Setup packages
Are you deploying HKCU or HKLM keys? I would not recommend writing any HKCU values from your setup, they should be written by the application itself. A setup is for writing to HKLM and other places that require "elevated rights". It should never be used to write user preferences. There will be interference when you do upgrades (as you have experienced).
Where is the registry data you speak of stored? In a single MSI component or several? Is there anything else in that component that still needs to be installed without the registry keys? If you can, please add your source WiX file so we can see for sure.
I am sure that we can make all these problems go away if you follow our advice precisely. You are facing a very common MSI problem.
Let me attempt a tentative answer without having all the information:
Remove all HKCU registry information from your setup (if you can).
Update your application to write these HKCU values itself, and ideally write to a brand new location in the registry instead of the old one. For example HKCU\Software\MyCompany\MyApp\5 instead of HKCU\Software\MyCompany\MyApp. This "decouples" your old and new state, and you got room to maneuver and clean up things.
Making your application write the HKCU keys is not a hack, but the right thing to do. It will make your application much more robust and generally easier to QA for yourself and your team. You can "wipe the slate clean" during testing and start over without a reinstall - in order to focus on application testing.
Put any remaining HKLM settings in a single WiX component and set a good key path that will never be modified or deleted by the user or any other process. For example: HKLM\Software\MyCompany\MyApp\5\MyAppHKLMKeyPath = 1
If you discover that you have to override a value for each user (in other words change something for every user in HKCU), you can do this with this approach which combines what the setup does with the application itself: http://forum.installsite.net/index.php?showtopic=21552 (if this is important, please read the whole, linked thread).
I used a wix generated msi file to install a software. Installing the software works fine, but sometimes there are some problems during uninstall.
All the files in "Programm Files" are removed as expected but after the uninstall, some data still remains on the system:
the app entry in "Programs and Features"
the installer in "C:\Windows\Installer\"
(and some registry entries which point to the two things above)
The problem is: as long as those data is on the system, it's not possible to reinstall the same version of the software. The installer shows the "Repair / Remove" action. None of them are working anymore.
But why does the installer not remove those files/entries?
What could be the problem?
Just some notes: when performing a MajorUpgrade, the new installer removes all the old entries. But this is not a solution.
Ans yes, all those registry entries and files can be removed by hand. After that a reinstall is possbile, but this is also no solution for the users.
This doesn't make much sense, primarily because installs and uninstalls are complete transactions, so that if an uninstall fails it will roll back and the entire product will still be there. It won't be a partial uninstall where some things stay and others are removed. Some things to look at are:
Do a log of the uninstall with msiexec /x {productcode} /l*vx [path to log file] to see if something shows there, for example if it finished successfully.
The \Windows\installer directory is full of msp, msi, mst files, so it's not clear what you mean about "the installer" being there because lots of cached installer files are there. Yours might be there too, I agree, if there is an entry in Programs and Features. That just means that there is still that product installed.
It's not clear why you mention upgrades, or what the entire scenario is. However you would get to your current situation if you had two installs where one was installed over the other incorrectly. Uninstalling one could remove all the files but leave a product behind.
Your system may no longer be clean if the same ProductCode has been used for multiple installs and testing, or you've attempted to clean things up with a tool like MsiZap. Start with a clean virtual machine every time, and see if you get the same issue. If this is happening on one test machine that might be scrambled due to repeated testing, then it could help to give your setup a new ProductCode and a new UpgradeCode.
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
I am trying to build a WIX installer MSI Package. While installation process I am doing some registry entries which needs reboot to take effect..
Well my question is,
How to reboot on 1st time/fresh install (not on upgrade) and that to without using custom actions? (custom actions are restricted by several AntiVirus programs, well that's another story)
I have tried ScheduleReboot After='InstallFinalize' with several conditions like :
NOT REINSTALL, REMOVE="ALL", NOT UPGRADINGPRODUCTCODE, NOT INSTALLED.. but still it's rebooting always, And I also have checked that if I remove
Thanks
NileshV
It's possible that Windows wants to reboot anyway - if that's needed it will happen, so you first need to be sure that it is not rebooting by skipping the ScheduleReboot completely. As Chroistopher points out, if you're not setting the REBOOT property then Windows will reboot you anyway.
The condition you want is Not Installed. Unfortunately property names are case sensitive and your spelling of INSTALLED is wrong.
I've written an installer in WiX; and it works very well. However, I've having a minor issue where the "reported" size of the installer seems to be growing with each subsequent installation.
Steps
Install application
Goto 'Control Panel' select 'Program and Features', find application and look at Size.
Uninstall applicaiton
Install applicaiton
Go back to 'Control Panel', select 'Program and Features', find applicaiton and look at Size again (it's grown roughly by the size of the installer).
Does anyone have any ideas how I stop the growth between installs? Or if this is by design?
Do your components have Permanent set to "yes"? These components are preserved even after uninstall. Look also for RemoveOnuninstall attributes.
Each program may or may not provide its own size information to Windows. WiX based programs typically do not and let Windows guess. (Search for ARPSIZE in your project to learn whether you do.) Consequently, Windows does not necessarily notice all of the files, but typically all the size reported is actually taken and worth researching via the file system. It may include files generated by your program somewhere under Program Files.
This size does not include space taken by the Windows Installer Cache. This is good to know about, too, as it is often as big as the installed software itself. The MSI is cached primarily to support easier uninstallation.
For a one-time cleanup of program related disk space you can use the Windows Cleanup utility.