I have an application (Installed as a service) that has 5 different versions. For testing I need to have all 5 installed. Currently I have to uninstall the application and reinstall the required version.
The application has a single exe (in Program Files\App) along some an xml file containing it's settings. This is installed via an MSI file. Each version has the same file\service name and checks for previous versions before installing.
Any ideas on a way to run all five versions at the same time?
First of all, I assume you're a developer, not the QA person. The QA need to use either virtual machines, or just 5 separate PCs. What I'm describing is a dirty hack that might save you some time.
Install version #1 to C:\program files\YourApp_1
Launch services.msc, stop the service, change the startup type to manual.
Launch regedit.exe.
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services key, find the key for your service, rename the service: change both the key name, the "DisplayName" value, and to simplify your life write something meaningful to the "Description" value, e.g. "MyApp 1.0 - this is the reference version".
If the installer checks some other keys before installing (it might be e.g. in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\YourApp), remove them. If you don't know those keys - use SysInternals ProcessMonitor to get them (set filter to instmsiw.exe or something, then launch the installer, wait for the "the prevoius version was found" message, alt-tab to the ProcessMonitor, stop logging, and read the log bottom-to-top)
Now install version #2 to C:\program files\YourApp_2, repeat the process.
At the end, to switch versions you'll only need to launch services.msc, stop the version that's currently running, start another one. Or use net start / net stop command line commands. Or whatever.
P.S. Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
Though this is more of a Sever Fault type of question:
http://www.microsoft.com/windows/virtual-pc/
There's yer answer :-)
Use virtual machines for each of your 5 different versions.
VMWare player is free: http://www.vmware.com/products/player/
Use VirtualBox.
Create one test system, configure it, then clone it 5 times (you'll have to use vboxmanage), and install one version on each of them.
If it wasn't a service, I had suggested Sandboxie, but I doubt that Sandboxie can handle services.
Related
My install fails on uninstall because of a bug in my CustomAction. I've fixed the bug, but I now have a test machine with that product installed and I can't get it to uninstall (keeps rolling back and staying).
In the past (years ago), I used msizap.exe that comes with the Windows SDK. But it doesn't seem to come with it anymore. I installed it and can't find it. My only guess is that it's no longer relevant in Windows 10.
Anyway, is there a best way to forcibly remove the product so that Windows no longer thinks it's installed?
msizap.exe: You are correct, msizap.exe has been deprecated long ago.
Broken Uninstall Workarounds: This problem is very common. You can find a list of approaches for these kind of uninstall problems here.
The easiest and fastest is probably to just use the Microsoft FixIt tool to remove the package. This basically "unregisters it" by the looks of it, and is similar to msizap.exe in that regard.
If this is just a single machine you can hack the cached installation database using Orca (how to find cached msi path, powershell version, using Windows Explorer - point 2) - if it involves many machines you should make a patch. Please see details in link above.
Virtual Machines: It is obvious, but just to mention that you should check setups on virtual machines so you can just revert the virtual machine when you encounter "development and QA bugs" like these.
Custom Action Flag: You can also add a condition to each custom action so that you can disable the whole custom action from running by a custom command line sent to msiexec.exe.
If your flag is a property RUNCA="1", then you can disable it by setting this flag property to 0 via the command line - this is sort of a little inoculation for the package's uninstall feature breaking - you can disable custom actions from running at all during install / uninstall - it might even be useful for your tech-support guys and real-world installations:
msiexec.exe /x {PRODUCT-CODE} RUNCA=0
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 trying to use this Visual Studio extension for 2013, which recreates the built-in installer functionality from Visual Studio 2008/2010: http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx?CommentPosted=true&PageIndex=2#comments
It works, allowing me to edit the project as before. It has the install and uninstall commands when right-clicking the install project, too. It installs fine.
When I try to uninstall, though, I get the following error and then the uninstall rolls back:
Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Wow6432Node\Microsoft\
EAPSIMMethods\18\FastReauthContext. Verify that you have sufficient
access to that key, or contact your support personnel.
I am not doing anything with that registry key, and there don't seem to be any relevant results on google-- at least not in the normal top 5 pages. Does anyone know what causes this or how I can fix it?
While I am not able to uninstall, I am able to increment the version of the package and allow it to remove the previous install and install the new version (all at once) successfully.
I am using Windows 8.1 Pro 64 bit, the projects are compiled for <AnyCPU>, and the installer is configured for x86.
EDIT I am running Visual Studio as Admin. When uninstalling from the Control Panel, I am also clicking the 'allow' button in the UAC dialog window that pops up.
I know how to give myself access to a registry key (permissions). I want to know why this key is trying to be removed. I support this app on several machines and I don't want to have worry about remembering an uninstall hack in the future.
EDIT This only seems to be an issue for a 32x installer on a 64x OS or a Windows 8 issue. I was able to use the same 32x installer to successfully uninstall the app on a 32x Windows 7 machine.
This must be an environmental problem, that key doesn't have anything to do with installers. EAP-SIM is an authentication protocol for wireless networks. The FastReauthContext key almost surely was meant to avoid having to provide a username+password each time your machine reconnects to the network. Which makes the registry key content very sensitive of course, it can only be read by a service that runs with the System account.
So, something goofy going on with your networking setup. Verify that you can successfully reconnect to such a network. If you used a VPN before then make sure it is active again. Something like this. Update your question with anything that might be relevant to networking when you first installed the app.
I have had similar problem and what I found out this is caused by MSI attempting to delete whole "Software\Microsoft" section in the registry. Lucky you that it encounters this error and rolls everything back.
So the solution is the following:
Since you have installed your program whenever you try to uninstall it the system will run msi from cache that is usually located C:\Windows\Installer.
Find your package in the cache. Here is an article that may help you http://csi-windows.com/blog/all/27-csi-news-general/334-identifying-cached-msi-packages-in-cwindowsinstaller-without-opening-them
Open the package in Orca. You must do this as administrator.
Go to Registry table and find record with "Software\Microsoft" as a key. Most likely the Name column will contain either "-" or "*" value. This means that during uninstall MSI will try to delete whole "Software\Microsoft".
Either change the Name value to empty or "+" or try to change key to something like "Microsoft". The second option will cause that installer will not find the key to delete during uninstall, but it will skip this error and let you uninstall your program.
You installed an untested installer on your dev machine? Speaking from experience, don't do that! Snapshotted VM's are cheap and will save you from this sort of pain.
Visual Studio Deployment Projects (or VSI as it's now called ) is known for creating very poor quality installs. The combination of those two put you where you are today.
I would need to look at the full uninstall log and your MSI using ORCA to understand exactly what is going on. MSI Zap and a manual cleanup of resources is probably required at this point.
I created a Visual Studio 2010 installer project and added the postgresql-9.2.401-windows.exe file to it. In the "Commit" custom action, I added that file, removed any arguments and set InstallerClass to False.
Now, when I run my application's installer, the PostgreSQL setup starts up, shows its splash screen and then jumps to 100% CPU usage and starts leaking memory for a long time (certainly longer than a few minutes), after which it bails out. Running the .exe on that computer works just fine.
How should I package PostgreSQL in my installer?
Personally I don't like programs that silently install the standard PostgreSQL for Windows. It's deeply annoying to get mailing list posts from people who're asking "What's this PostgreSQL thing and why is it using 88 bajillion megabytes of RAM, I didn't ask for it, remove it now!".
(Yes, I'm mostly talking about a certain annoying gambling card-counting program with the initials PT whose name I will not mention directly).
If you're going to bundle PostgreSQL it'd be great if you could use a non-default port and non-default data directory. If you install a service to auto-start it, don't use the default service name postgresql-[version] but something like myapp-database or myapp-postgres.
This is all done much more easily if you just bundle the PostgreSQL binaries in your installer then create the service yourself with your installer tools or via sc.exe. You may choose to simply pg_ctl start/stop the server from within your program, though this requires some thought about access permissions to the data directory.
The downside is that when there are PostgreSQL updates you need to update your installer. On the other hand, you probably don't want people upgrading PostgreSQL independently of your software updates.
I suggest using the .zip binaries from here and bundling them into your installer directly.
If you really must use the executable installer the documentation contains instructions on silent installation.
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.