We have an installer wizard (written in .NET) which configures and kicks off a series of standard Windows installers. The installers are run silently. Right now, clicking "Cancel" on the wizard's dialog stops further installers from running, but does not stop whatever installer is running silently in the background.
Is there a way to send a installer running silently the equivalent of pressing the Cancel button on a non-silent install? (I could kill the installer process, but I expect that that will leave a half-installed (and probably non-uninstallable) mess behind.)
I'm not sure if you're creating new instances of these installers within your own installation wizard so I don't know how applicable this solution is going to be, but if you do have access to the actual (derived) System.Installer objects that correspond to the installers, calling the overridden System.Installer.Rollback() method of those objects should achieve the desired result. Let me know if this doesn't work and I can try helping you further.
Related
How can I abort a Windows Installer using VB Script that when it choose a certain option, the installer will force end?
I am using Visual Studio 2010 Setup Project:
Here is the pseudocode for it:
MSGBOX "Do you want to continue installing?"
IF Press YES { Continue Installing }
If Press NO { Abort/Exit the installation process. }
End
I expect this final window to appear after I press NO:
It might help if you said something about what the incorrect option is. It might be something in a dialog (like TextBoxes) that you've added to the UI and you can't validate it because VS setups have no support for custom actions to run during the UI to validate entered data.
Either way, all custom actions in VS setups run after all the files are installed and the setup is virtually complete. In other words the only place to validate your data is after the install has finished when it's too late to stop the installation. All you can do is return an error from the VB Script and have the whole setup abort and roll back, and I don't think that's what you want.
If you really need this kind of functionality you need a tool that has support for it, somewhere in the dozens of tools that can create MSI files.
In a more functional tool I don't think you'd use a dialog choice like that. The dialog that offered the choice would have a custom action validate the data when the Next button is clicked. If the data is incorrect then the Next button stays disabled. If it is potentially incorrect a warning can appear on the dialog, but there is a Cancel-type button on every install dialog I've seen, so you don't need to abort anything - tell the user to cancel. But most dialogs have a back button to go back and change data too. In other words your UI flow isn't typical of most wizard-type flows in installs and therefore could be confusing.
I'm trying to build a package and deploy it silently. I have the script ready executing an exe silently, however since the exe uninstalls a program, I still see the window "Configuring..." pop up. I am using
Set Shell = CreateObject("WScript.Shell")
Shell.Run("Uninstaller.exe 0,true)
This is working fine, as in it's running the uninstaller silently, however once the uninstaller starts doing its job, another window pops up saying "configuring application name". Is there a way to hide that?
It seems that the window you are seeing is part of the .EXE you're running.
Perhaps the "Uninstaller.exe" has a switch or parameter to make it run silently?
EDIT
If you can use a 3rd party tool, AutoIt provides an easy way to hide a window. Look at the WinSetState function.
I'm using Microsoft Visual Studio 2010 to create a simple .MSI installer for my simple .EXE application.
Trouble is, things go wrong (until a reboot) if you install an upgrade while the .EXE is still running.
I'd like for the .MSI installer to terminate my process before installing/upgrading.
Please could someone tell me how to do this in Orca?
EDIT: I've seen this occur due to my .EXE being in use, but I've also seen it because the .CHM help file was open at time of upgrade as well, so any process termination alone is not enough to solve this problem.
You should ad the MsiRMFilesInUse Dialog to your installer.
You can try creating a custom action which stops your application (a custom EXE or DLL written by you). For example you can send WM_CLOSE to the main application window (your application should handle this message).
This custom action should be scheduled before InstallValidate action in InstallExecuteSequence table.
You could write a custom action that closes your application as well as your help file.
You should be able to find the window handles for both of these by using FindWindow:
http://msdn.microsoft.com/en-us/library/ms633499(v=vs.85).aspx
For the executable, you should be able to use the appropriate Window Class or Title for FindWindow.
For the help file, you should be able to use the appropriate Help Window Title for FindWindow.
I hope this helps!
When a normal user runs a WiX installer which requires elevation, there appears to be a delay of 30 seconds or more between the user clicks the "Install" button and the UAC prompt comes up. This happens even though the install button is marked with the UAC shield, suggesting the installer "knows" that elevation will be required.
Is there a way to IMMEDIATELY throw up the UAC when the user 1) runs the installer or 2) clicks that "Install" button?
The length of time for the UAC prompt to come up depends on the size of the exe. (Try it yourself by right-click run as admin various exes of various sizes.) Therefore I have heard it suggested that you make a teeny launcher exe that will bring the prompt up quickly, and have it launch everything else. Anything launched from an elevated process is elevated.
Be sure to name your launcher well, for the 1% of users who actually read the UAC prompts.
How big is your MSI file? I don't know for a fact, but I think splitting your files into a separate .cab file and possibly digitally signing it might make the validation of the MSI file go faster.
Otherwise, there really isn't anything you can do about it to my knowledge. I hope someone proves me wrong. :-)
I am currently working on a program to immediately clear the list of previously-run-commands which appears in the Windows Start -> Run dialog. The procedure for clearing this list by removing the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU key is well documented; however, before these changes take effect, it seems to be necessary to do one of the following:
Restart the computer
Select Start -> Shut down, and then select Cancel.
Neither of these is ideal for the task I am trying to accomplish: #1 is extremely disruptive to the user, and #2 appears to require additional user interaction.
Does anyone know how to immediately (and programmatically) force a reload of this information without requiring any user interaction, while also minimizing disruption of the user's other activities? I would like for the user's Run history to be cleared out immediately after executing my program, without requiring any further action on their part (such as using the "Shut Down" -> "Cancel" trick in #2 above) or forcing a reboot.
Or, to approach the problem from a different angle: When clicking Start -> Shut Down -> Cancel, Windows Explorer reloads the RunMUI key. Is there a way to force a similar reload without having the user select Shut Down and then Cancel?
Things I have already tried:
Monitoring the explorer.exe status using procmon while selecting Shutdown and then Cancel. I see Explorer writing to the RunMRU key, but have not been able to determine what triggers this.
Numerous Google searches along the lines of "reload runmru without reboot". Most results still recommend method #1 above, although a few suggest #2.
Limited MSDN API examination. The RegFlushKey call appears promising, but I haven't ever used it before, so I don't know if it will apply to registry information cached by different processes.
Any suggestions or other information would be greatly appreciated.
Have you tried ccleaner?
http://www.ccleaner.com/
Not a full answer to your question, but I did find a third way to trigger the clearing of the run command from this article in PC Mag.
Killing explorer.exe and then restarting it will also clear the run list after the registry modification.
I have a nasty hack for you. Show the window programatically, hide it immediately (programatically) and click cancel on it (well, you guessed, programmatically).
You might try looking for the icon cache flush API, or other ones, I wouldn't be too suprised if they had side effects like the one you are looking for.
I've seen instances where it actually works, even the F5 key doesn't work? Try this, ctrl>alt>delete then go to task manager, processes tab...end explorer.exe. Then click on file new task and type explorer.exe, then check...does that work?
Windows XP
Right click on the taskbar
Properties menu option
Start Menu tab
Customize button
Programs pane
Clear List
Click on OK
This calls a Windows API function that refreshes the explorere.exe taskbar process and also clears the list (no need for registry edits).
As far as I know, it relies on the explorer.exe process that hosts the start menu/taskbar/desktop being closed and reopened. There is no "clean" way to do this that I am aware of.
If you really need to do this without user interaction, you need to close all explorer.exe processes and relaunch one.
Here's a rudimentary C# program to do that;
using System.Diagnostics;
Process[] procs = Process.GetProcessesByName("explorer");
foreach (Process proc in procs)
{
proc.Kill();
}
Process.Start("explorer.exe");
Note that this will close all "Windows Explorer" windows open, and may or may not open an additional "Windows Explorer" afterwards.
I just tested that on Windows XP 32bit, and it did indeed clear the Run command cache.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ RunMRU\