I have a complex installer (Wix) that is in multiple parts. One part installs some camera drivers (32 OR 64 bit depending on what is called for) via an EXE file, NOT AN MSI FILE. Once my app is installed, using Wix, the camera drivers/executable appear in Programs and Features in my Control Panel. Before I can upgrade my app, I have to uninstall the camera drivers (and then install the latest version). There is no uninstall EXE/MSI in the camera's install directory. I can figure out how to check if the camera is installed (although I'm not there yet), but how do I uninstall the camera w/o manually going to control panel. How do I automate this process?
Note: I look thoroughly online for a solution, and while a lot of threads came close, nothing actually answered this question.
Note: after more searching, I ran across WMIC(http://www.tech-recipes.com/rx/2947/windows_uninstall_application_command_line/). Can I automate via WMIC? To make things even stranger, my camera doesn't show up in the WMIC list, it IS in Control Panel though.
Thanks in advance!
-Dan
If the command appears in the Add/Remove programs applet, then the information is available in the Uninstall Registry keys. By enumerating the entries in this registry key, you should be able to determine the information necessary to perform an uninstall of the component in question. Typically the UninstallString gives the proper invocation syntax to uninstall the component without needing any user interaction.
Some applications have specific behaviours, and you can have both a ModifyPath and UninstallString option in the registry. The ModifyPath option would be for the check/reinstall/fix/add-remove items options, while the UninstallString should perform an uninstallation, hopefully without needing user interaction.
For the app in question, it takes the program name and the /uninstall parameter to get it uninstalled in this case without having to press any options.
Some uninstallers take the /q or /quiet option which performs the uninstallation without any user interaction - this is all down to the app in question.
Related
When users try to uninstall their own single user installation (for example installed using lowestprivileges none and HKCU entries) with 'Add/Remove Programs' in the Control Panel, everything works fine (that is, non-admin users can uninstall their own non-admin installation).
However the uninstaller will be elevated, when users start it from 'Apps & features' (Windows 10).
This seems to be a known Windows 10 bug:
How to prevent uninstaller elevating for Standard Windows 10 user?
Is there a way to work-around this issue when the Inno Setup uninstaller is started from 'Apps & features'?
Link this NSIS Workaround for Windows uninstaller elevation bug.
You will have to do exactly what that NSIS hack does.
Find out what is the Windows GUI user (and assume that you should uninstall as that user). Alternatively, you can store the username into some file in the installation folder.
Re-execute the installer as that user. That hack uses StdUtils NSIS plug-in with its ExecShellAsUser function. Maybe the DLL can be used from Inno Setup. If not, you can at least reuse its code.
All this is imo to much to ask in a single question. If you have specific problems, consider asking more specific questions.
Simpler alternative would be to prevent the uninstallation, when executed as different user, and show a suggestion to the user to go to Control panel instead.
For a similar question, see Uninstaller trouble with standard Windows 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 use the following command to run a exe file which is in the network drive through a vbscript:
wsh.Run """\\lonmsc01\apps$\EWebEditPro\Version 4\ewebeditproclient4.exe"""
This installation pops up with dialog boxes to choose the setup type As Resintall or Remove and proceeds on by clicking on Next to finish the set up.
Is there any way I could disable the UI and install it silently?
The whole idea of using vbscript to silently install software is a bad idea. User interaction or at least user notification should be involved in all software installations unless you're a network admin using an Enterprise management tool. This struck me as sneaky, so I did a search for the exe you mentioned.
A quick google search indicates this may be malware you're trying to install... At least according to the Prevx site, it's listed as potential spyware. You're not asking us for help in silently installing malware, are you?
At any rate, even if this is legit (which it probably is) it's a bad idea. In today's world, silent installs should be completely disallowed.
http://spywarefiles.prevx.com/spywarefilesweek.asp?mk=43998135
Depends on what setup utility was used. Mose installers have a silent or quiet operator. Try calling the setup with the parameter /?, it might tell which parameters you can pass him. Or you just try different switches, like /silent, /quiet etc.
I am creating windows installer project using Visual Studio 2005.
Is there an option make it so that my project does NOT have an uninstall option in Add/Remove programs?
One of my customers has asked me to do this.. Here's Why: Because the installer is a patch to an existing program. After uninstalling, the program no longer works because the patched files get uninstalled. Instead of figuring out a way to restore the replaced files (which we haven't been able to do with this installer), we're wondering if it is possible to disable the uninstall.
You just need to set ARPSYSTEMCOMPONENT=1 in the Property table of the installer using Orca (Can't be done directly in Visual Studio from what I know)
This is commonly used when a program installs dependencies and you don't want the user to uninstall dependencies by hand, they need to use a specific uninstall script you've provided or something.
Personally, I would author the patch as a patch and prevent the patch from being uninstalled.
Also I suggest picking up a copy of The Definitive Guide to Windows Installer which will give you some explanation on how, why and where you should use tricks such as this. As well as giving you a really good understanding of the windows installer fundementals and help you to design a better installer in the long run. All the examples in the book use Visual Studio + free tools from the Windows Installer SDK.
Edit: The user still has full control to uninstall via MSIEXEC, via a custom uninstall shortcut that you provide, all this does is hide the entry in Add/Remove Programs (ARP)
Edit2: Sample VBS to add the property (if you want to do so as part of an automated build process)
Dim installer, database, view
Set installer = CreateObject("WindowsInstaller.Installer")
Set database = installer.OpenDatabase ("test.msi", 1)
Set view = database.OpenView ("INSERT INTO Property(Property.Property, Property.Value) VALUES('ARPSYSTEMCOMPONENT', '1')")
view.Execute
Set database = Nothing
Set installer = Nothing
There might be, but to be honest, that's a horrible, horrible idea. It's not your call to tell a user what they can and cannot do with their machine.
And if the user shouldn't have the ability to do so, then that is usually determined by an administrator and the user is not given the right to uninstall anything by virtue of their account type, which again, is not something you should have influence on.
You don't know who his "users" are. This may not be for end-user software at all. We write a lot of custom software that's installed in a NOC; it doesn't put any uninstall info into add/remove. (We're using Nullsoft's NSIS and not the Visual Studio installer, btw...)
It's way too silly to say something like "This is always a horrible idea". There are many cases in modern software where uninstalling dependencies can true and thoroughly f--- the machine at hand up.
Open Source Software ideals are only useful for people who WANT to be able to break their machine.
I just noticed that Chromium was installed in AppData in both Vista and XP. If Google does that and if other applications does this, than is that becuase there is some form of protection? Should we write installers that does the same thing as Google?
Windows still lacks a convention for per-user installation.
When an installer asks whether to install for the current user or all users, it really only refers to shortcut placement (Start Menu; Desktop). The actual application files still go in the system-wide %PROGRAMFILES%.
Microsoft's own ClickOnce works around this by creating a completely non-standard %USERPROFILE%\Local Settings\Apps (%USERPROFILE%\AppData\Roaming on Vista / Server 2008) directory, with both program files and configuration data in there.
(I'm at a loss why Microsoft couldn't add a per-user Program Files directory in Vista. For example, in OS X, you can create a ~/Applications, and the Finder will give it an appropriate icon. Apps like CrossOver and Adobe AIR automatically use that, defaulting to per-user apps. Thus, no permissions issues.)
What you probably should do: if the user is not an admin, install in the user directory; if they do, give them both options.
One advantage nobody mentioned are silent auto-updates. Chrome has an updater process that runs all the time and immediately updates your chrome installation.
I think their use-case is non-standard. They need a way to fix vulnerability issues (since it's a browser) as soon as possible. Waiting for admins approving every single update company-wide, is simply not good enough.
As far as I can tell, the only reason why Chrome installs into the Application Data folder is so that non-admin users can install it.
The Chrome installer currently does not allow the user to pick where the application is to be installed. Don't do that – instead, give the user a choice between a per-user (somewhere like App Data) and computer-wide (Program Files) installation.
Windows 7 and Windows Installer 5.0 provide real per-user installation capabilities now.
http://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx
You can sort of fudge it in Vista and XP by using ~/AppData/Local or the equivalent like Chrome does. Microsoft themselves use this for the ClickOnce installers.
So at least on Windows 7 and beyond the solution is simple.
Frankly, I have yet to see the first installer that really allows both per-user and per-machine installations. Many installers offer this option in their GUI, but the setting only affects where the shortcuts etc. go -- the binaries always fo to %ProgramFiles%.
In fact, it is pretty hard to create Windows Installer packages that allow both kinds of installs, to say the least. With the advent of UAC, I'd say its is impossible: Per user installations must not require elevation, per machine installations have to. But whether an MSI package requires elevation is controlled via a bit in the summary information stream -- there is no way to have user input have impact on that.
Whether per-user or per-machine is the better choice greatly deoends on the application. For small packages, however, I tend to prefer per-user installations. Besides being slightly more user-friendly by not requiring an UAC prompt or runas, they also signalize the user that the setup will not do much harm to the computer (assuming he is a non-admin).
The Chrome installer really ought to allow global installation (with elevation) in addition to per-user. I don't want to have to maintain an installation for every user; I want to be able to centrally manage upgrades and so on. Chrome doesn't allow that.
That said, the option to install per-user is quite nice, as it means no permissions issues.
Just so you people know, Google has created an MSI installer for global system installation and management. It's located here:
https://www.google.com/intl/en/chrome/business/browser/
I do not see anything in %PROGRAMFILES% on Win7. Looks like Chrome must be installed for each user on the machine.
Perhaps the true reason of doing this is faking number of Chrome installations by few times ! Thus making it first browser in the world !