while uninstalling one msi package through control panel. In task bar i notice that the msiexec.exe with commandLine \x was not getting called but still the msi package got uninstalled. In registry where that particular software was stored in that they have provided uninstallstring in which something like this is given "MsiExec.exe /X{2012098D-EEE9-4769-8DD3-B038050854D4}".
so there are other way through which it does uninstall the software without calling Msiexec.exe??
and if it does then how ??
can someone please enlighten me on this
For Windows Installer products the UninstallString in the registry is not used. Windows simply calls the API to do the uninstall. Yes, sometimes that's a pain if you'd like to customize the uninstall to do something different, but that's the way it works.
The legacy way of adding a program to the ARP (Add/Remove Programs control panel) is to specify the uninstaller's command string (e.g. c:\app\uninstall.exe) in either of the following registry keys:
KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
OR
KEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall
And the path to the uninstaller is specified by the "UninstallString" value for each subkey
Installer's that do not use MSI use exactly this technique to show up in ARP to suppor uninstall.
More details here:
http://msdn.microsoft.com/en-us/library/aa372105%28v=vs.85%29.aspx
msiexec.exe is the general process used for install / uninstall task. It takes as an argument the specific program id / class id which is of the form GUID - the long hex string you posted.
Even if you don't see it executing with /x switch, it is silently passed this string when you choose to uninstall something right from control panel - the result of which is uninstallation.
Related
I have a Wix script with a RemoveRegistryValue element. It correctly removes the registry value when I install the product (provided I run with elevated privilege, which I am now). However, when I uninstall the product the registry value is not replaced.
If I wanted the value removed and never to be seen again I could have just gone into regedit and removed it. The whole idea of putting the removal in a Windows Installer package is so that I could uninstall the package and put everything back as it was should I need to. However this is not happening.
<RemoveRegistryValue Id='ShowLnk' Root ='HKLM'
Key='SOFTWARE\Classes\Lnkfile' Name ='NeverShowExt' />
On installation the value is removed (causing shortcuts to display their .lnk extension if you must know what it does). On uninstallation the registry value is not replaced (causing shortcuts to display their .lnk extensions forever, which is likely a good thing, but not relevant to this discussion).
How do I get the registry value back into the registry on uninstalling my product?
I've followed on now with another question here...Getting a custom action to run on install and uninstall
On uninstall, Windows Installer only "undoes" things that it actually created on the local machine during installation.
"Side effects" like removal of registry keys/values and files will not be undone during uninstall (though when a rollback happens, these will be undone as expected).
To support your scenario you have to do backup and restore of the registry value yourself:
On install:
Use RegistrySearch to get the existing value of 'NeverShowExt'. You may need to set Win64="yes", I'm not sure about that.
Store a backup of the value in your apps registry key (HKLM\Software\[Manufacturer]\YourProductKey).
On uninstall:
Use RegistrySearch to get the backup value from your apps registry key.
Create a deferred custom action that writes the registry value back to its original location. There is no declarative "WiX way" to write something to the registry upon uninstall.
I created an MSI installer project in VS2015, set up everything, then added a file extension associtation with the "File Types Editor", assigned my extension to my application, as an Open command.
The COMMAND was the application from the "application folder", the EXTENSION was set, then the &OPEN was set as NAME=&Open, Arguments="%1" VERB=open. Nothing else.
I generated the .msi file, then started. At the end of the installation, I found out that in the registry Computer\HKEY_CLASSES_ROOT\\shell\open\command key there were two item, one is (Default) REG_SZ with value "myexe" "%1" as I expected
Unfortunately there was another item: "command", "REG_MULTI_SZ" and the Data was something weird, for example "LZ*a!t4(v=++Tt$)tOk_>[1jfrS!,nB`L6ciHLW!, "%1"" which I don't know what it is. When I delete the .msi file, and double click on a file with my registered extension, a popup dialog appears as "network resource cannot be found" and Windows wants my .msi installer back (browse dialog comes in)! I don't know how to prevent this unwanted situation. :( Any help would be highly appreciate!
Windows Installer uses so-called Darwin Descriptors to implement resiliency, wherein a corrupted installation can be repaired automatically. Your attempt to delete the .msi rather than to uninstall it acts like a corrupted installation, so the system attempts to fix it. However, since the .msi itself has been removed, it has to ask for help.
The short answer here is to suggest that you not worry about the exact values in the registry key. Since you're using an Extension table instead of a Registry table entry, the registry is an implementation detail; you should prefer to ignore such detail. Instead, if after a successful installation your program launches as expected upon double clicking the associated file, and it stops doing so after properly uninstalling your application, all is well.
I've made a custom installer / uninstaller. I register the uninstaller with the Windows Registry as described in the MSDN Library, Chaper 2. Install/Uninstall.
Namely, this means registering uninstall.exe as the UninstallString. It works, in that it runs my uninstaller. The problem is that it doesn't invoke as admin. I've set uninstall.exe's manifest to require admin using mt, and if you double-click it from explorer, it will automatically request admin as desired.
So the question is, what's the magic flag I need to set in the registry to get the Windows Add / Remove Programs dialog to run my uninstaller as admin?
You could add checking for admin privileges inside your uninstall program. Check this question for more ideas on how to do it. The easiest of the mentioned options is using a shortcut to your program and ticking the option "Run as administrator".
The other solution is to make a registry entry inside HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers and add a REG_SZ path to your executable as the value, and "RUNASADMIN" as data.
More info in this answer here.
Where is in the registry the path executed when I run the "notepad" command in windows "Start->run command" interface? I want to change it for notepad++ (it is required so, although could look not really good)
If you are like me you use windows run command all the time. I hate using the mouse to point and click a shortcut on the start menu. WIN-R are probably the two most over used keys on my keyboard. After thinking about if awhile I hunted down how the run command works. It turns out that it makes a call to ShellExecute, which I guess is not too surprising. The next thing I wanted to find out was exactly how the commands are resolved. The following is an ordered list of how they are resolved ([1]):
The current working directory
The Windows directory (no subdirectories are searched)
The Windows\System32 directory
Directories listed in the PATH environment variable
The App Paths registry key
Naturally the next thing I wanted to do was customize existing commands or add new commands so I do not have to type as much (standard lazy approach). After examining my options which were to put the executable in one of those paths (since it only locates executables and not shortcuts), modify the path environment variable or add a key to App Paths. The App Paths option seems to be the easiest and most flexible to me. Here is a layout of what you need to do to add an App Paths entry ([1]):
HKEY_LOCAL_MACHINE-->
SOFTWARE-->
Microsoft-->
Windows-->
CurrentVersion==>
App Paths-->
file.exe-->
(Default) = The fully-qualified path and file name
Path = A semicolon-separated list of directories
DropTarget = {CLSID}
Disclaimer: Modifying the registry can cause serious problems that may require you to reinstall your operating system. I cannot guarantee that problems resulting from modifications to the registry can be solved. Use the information provided at your own risk.
The minimum needed to add a new entry is to add the key file.exe where file is the string you want to type into the run command and to add the Default entry which is the fully-qualified path to the file you want to execute. Note that even it the file you are going to reference isn't an exe file you still need to put the .exe on the key. Here is a sample registry file that I created to add a shorter keyword for Internet Explorer:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\ie.exe] #="C:\Program Files\Internet Explorer\iexplore.exe"
After entering that entry into the registry I can simply type “ie” at
the run command to open internet explorer.
Here is a list of some common commands I use at the run command:
cmd – Command prompt winword – Microsoft Word excel – Microsoft Excel
outlook – Microsoft Outlook iexplore – Internet Explorer firefox –
Mozilla Firefox notepad – Notepad compmgmt.msc – Computer Management
Console control appwiz.cpl – Add/Remove programs dialog mstsc –
Microsoft Terminal Service Client regedit – Registry Editor
…
If there is some program that I find myself using all the time I figure out what the run command is for it and if there is not a short easy one I add one to my App Paths as described above. Does anyone else have some other common run commands they use?
When I run an MSI (without parameters) I usually have to click my way through dialog boxes and choose if I want to install to current user/all users, the target directory, etc etc.
What happens when I run the MSI with /qn (silent mode). How do I find what answers where automatically chosen for all those dialog boxes?
An MSI is a basically a database. You can use Orca to open it and view/change settings.
Information on Orca can be found
here.
A quick walkthrough on how
to use Orca can be found here.
Somewhat pertaining to your
question, you can edit which users
the installer will install in silent
mode. Information is here.
I hope this has at least geared you in the right direction.
Edit:
For instance, download the installer for WiX 3.0 and open it in Orca.
Go to the Property table and you will see a list of public (uppercase) and private properties.
Notice that the WIXUI_INSTALLDIR property is set to APPLICATIONFOLDER.
Go to the Directory table, you'll see that APPLICATIONFOLDER is set to have a default of "vqee3ld3|Windows Installer XML v3" or something similar.
To find which dialog sets this property, go to the ControlEvent table. Here, you'll see the InstallDirDlg fires the event SetTargetPath when the user clicks the Next control. The Argument this event sets is WIXUI_INSTALLDIR, which in turn sets APPLICATIONFOLDER
You could try editing these properties and running the installer to see how the properties are changed. If you have default properties you'd like to set you can run. For instance, close Orca to release the lock on the msi file and run:
msiexec /i Wix3.msi APPLICATIONFOLDER="C:\Program Files\WiX" /qn
More on MSI table structures in this powerpoint
It is correct that you can set PUBLIC properties via the command line. These properties are always uppercase, and generally always listed in the Property table, though this isn't guaranteed to be the case. By reviewing the Property table you should be able to decode what each public property does. If not, there is usually documentation accompanying the MSI in form of a PDF or readme.txt that can help.
With the right tool you can also view the details of each MSI dialog and check the events that have been defined to set them. This requires a tool such as Installshield or Wise.
Another possible option for silent installation is a built-in MSI feature that I have just become aware of: the AdminProperties property. See information here: http://msdn.microsoft.com/en-us/library/aa367542(v=vs.85).aspx