i am having a msi setup file which installs a windows service on the system. Now everytime i install a newer version of the setup, i want that it should first completely uninstall the previously installed version and then install the current version. I am pretty new to these configuration so not having any idea on this.
Any help would be much appreciated.
Thanks in Advance!
You will have to ensure that when you run uninstall on the first version of your application that it really does leave your system in the original state you expect. Unfortunately, depending upon your setup and application, a clean uninstall is not automatically guaranteed simply because you ran uninstall on the same Windows Installer package used to install the application. You will need to test the original installation package thoroughly to ensure that Uninstallation Leaves the User's Computer in a Clean State. For example, if your application must be registered, the installation package must be authored to clean up the registry when the application is uninstalled.
If your installation package actually does always leave the user's computer in a clean state, then you can remove an application that has been installed using a Windows Installer Package by using the Standard Command Line Option with the /uninstall option, or one of the Windows Installer APIs such as MsiInstallProduct.
If you want to install a newer version of your application over an older version that is already installed, it may be better to develop an update package to update the application. There are several types of updates: Small Updates, Minor Upgrades, and Major Upgrades. See Patching and Upgrades in the documentation to determine what type of updating package you will need to provide to the users of your application.
One of the purposes of the Windows Installer is to support application servicing like this where there may be shared components and multiple updates on the user's system. This can be a more resilient servicing approach because it can require less prior knowledge of the user's computer than an approach of rip-out and replace.
Related
I know how does Cask works and all the benefits I can get when using it in a brand new system, but what I want to know and I don't seem to find and answer anywhere is... would it be a good idea if I delete my previous installed software and replace them with cask versions? would I see some kind of improvement, or would it be a waste of time?
There's no real advantage to reinstalling existing binaries using homebrew-cask. It's strictly a workflow improvement for when you need to install various softwares. For instance, if you wanted to have a script to install all your regularly used binaries on a new computer, that would be more efficient than manually visiting several sites and downloading, installing, etc.
Traditional software installation on some apps have automatic updates and some require the user to visit the apps website to do an update. Once the update is downloaded the user is required to click next, next, agree etc whilst it is satisfactory to do this for a few apps it can be time consuming.
One of the advantages of HBC is that it does an install without user interaction or sometimes a prompt for admin password. So if you do a reinstall of the OS you can use HBC to reinstall the additional apps.
At present there is no provision for updates using HBC so i have written scripts that take of some issues.
The scripts will create a file that lists the files to be updated including apps that are defined as latest. You can then modify the file to suit your requirements and install updates using my olinst script.
For more information visit my github.
https://github.com/pacav69/homebrew-homebrew-caskroom-offline-installer
I am having trouble uninstalling a package from Windows 7 that I myself have created with InstallShield.
Running remove program from control panel only got 1/2 way before it aborted and rolled back.
Funnily it reported the problem being one of my install steps, not one of the uninstall steps.
Frustrated I used the Windows Install Cleanup and the package is no longer listed under Remove programs.
However when I try to run the installer once more it reports that a previous version of the software must be uninstalled before it can proceed.
I was guessing that the Unique ID was still present in the registry but is not.
How exactly does windows determine that a previous version of the software is installed on my machine?
The best solution to an uninstall issue that prevents the product from being uninstalled is to debug the issue (often a custom action) and fix it or delete it, then rebuild the MSI with the same ProductCode. Then reinstall it with a command line:
msiexec /I [path to msi file] REINSTALL=ALL REINSTALLMODE=vomus
which updates the product in place and the re-cached fixed product will now uninstall. Otherwise (because you can't recreate the MSI) it is possible to go into the cached MSI in C:\Windows\installer and change the MSI manually with Orca, conditioning CAs not to run, for example. But you need to know what you're doing.
In other words and unfortunately, it would have been better to get the uninstall issue dealt with before resorting to the installer clean up utility, which I believe may no longer be supported because it doesn't completely clean up the system.
Your best approach now is to change your ProductCode, UpgradeCode and PackageCode because they'll be among the items on the system that Windows will use to see that your product is already installed. This stuff is in the registry, but it's obfuscated (rearranged guids) and scattered around.
Thank you in advance for considering this question. If a similar question existed, I was unable to find it.
The Issue: Our company packages an application into an MSI. This MSI when installed outside of any GPO properly updates, blocks attempts to downgrade (or move from a higher revision to a lower revision), and never has trouble uninstalling previous versions of the application regardless of how long ago those versions were created/installed. For example, we can install version 1.2.3 and then install version 2.3.4 and the application will properly install without issue. However, we work with a customer who uses GPO to deploy our application to hundreds of PC's. Each time we have provided an updated version of the application the following has been indicated:
On any machine where a previous version of our application was installed via GPO, no matter what the previous version is, the update successfully installs without issue.
On a machine where the application was manually installed (outside of the GPO), and an attempt to update the application via GPO is made - either the application is installed in addition to the old version, OR there remain registry keys to the previous version of the application and the application cannot open/run correctly. In this case the registry keys must be manually removed, and the install is then attempted again from a clean machine.
What we know is that on any machine where the application was originally installed via GPO - updating the application is no problem. On every machine where the application was not installed with the GPO in the first place, updating via GPO fails with one of the problems presented above.
My question is: Is there a technical issue with how the installation is being handled partially through the GPO and partially outside? Does the GPO need to be responsible for the entire life-cycle of the application? OR is it a reasonable expectation that the application be updated both on machines where the original version was manually (outside the GPO ) installed, and when it was installed initially from within the GPO?
One solution we are aware of is simply having all computers manage the application life-cycle (since we know updates work in that environment already), however this would mean that many computers would need to have the manually installed versions removed by hand - and then properly handle the installation through GPO which is an extensive bit of work.
We would greatly welcome any solutions, references to technical documentation that formally shed light on the proper management or expectations here, or links to information. Our research suggests that it is "best" to manage the entire applications life-cycle inside the GPO - but I have as of yet been unable to determine that it is 100% necessary to do so.
Looking forward to any assistance. If any further technical details are required to help the viability of the question, please don't hesitate to request such details.
If you end up with two versions installed in Control Panel, then all other things being correct, the most likely explanation is that you upgraded a per user install with a per machine install (or vice versa). In the GPO world that's related to assigning it to a user or to the computer, something like that. That's easy to verify by getting a verbose log and checking the FindRelatedProducts actions for an indication that another product was found but in a different context.
When you're in GPO mode all the time, I assume each one (whether it's per user or per machine) is consistent, therefore upgrades always work, but they don't work cross-context.
I believe GPO suppresses the UI in most cases, and the UI (or the UI sequence) is sometimes where per user/per machine is set. That might be something else that would cause it, depending on how the GPO publishes to the computer or the user.
I'm writing a new installer for our legacy software. The installer was originally built with InstallShield Professional 6.40, and I'm now building it in Inno Setup. Because of major changes in the software's infrastructure, I need to first uninstall the old one so that I can perform a fresh installation using the new one (using Inno Setup).
The old version was installed in the drive's root (C:\SoftwareName\) And now I'm moving it to its appropriate place in the Program Files - as well as changing the registry key names. So although it's the same software, it's really treated as a completely different software.
I have found the entries in the registry for the old installation:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{[OUR GUID]}
And in here, there is an entry for uninstall information in UninstallString:
RunDll32 C:\PROGRA~2\COMMON~1\INSTAL~1\engine\6\INTEL3~1\Ctor.dll,LaunchSetup "C:\Program Files (x86)\InstallShield Installation Information\{[OUR GUID]}\Setup.exe"
The second part of that, I know I can execute to launch the "Modify / Uninstall" wizard. But this needs to be automated, showing only the progress of uninstalling.
I've found the following links:
http://www.symantec.com/connect/blogs/various-silent-parameters-uninstalling-installshield-applications
http://pic.dhe.ibm.com/infocenter/pcomhelp/v6r0/index.jsp?topic=%2Fcom.ibm.pcomm.doc%2Fbooks%2Fhtml%2Finstall_guide12.htm
But these appear to refer to newer versions of InstallShield. Our installation was with a very old one (6.40). I've managed to use that wisdom at least to initiate the uninstall like so...
RunDll32 C:\PROGRA~2\COMMON~1\INSTAL~1\engine\6\INTEL3~1\Ctor.dll,LaunchSetup "C:\Program Files (x86)\InstallShield Installation Information\{[OUR GUID]}\Setup.exe" -10x9 -uninst -s -w
But it still gives a yes/no prompt if user wishes to uninstall...
This process is supposed to...
Run silently with no wizard or user prompts
Display just the progress of uninstall
Wait until uninstall is complete before returning
But I have no luck accomplishing those things.
What's the appropriate way to perform this uninstall?
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.