I need the ability to look for another running process that is in the background while my NSIS installer is executing. This other process must be terminated and uninstalled before the new installer is completed.
I've tried using the FindProc plugin to find the process and also the KillProc plugin to kill the process. Each of those plug-ins returns nothing as a result.
FindProcDLL::FindProc "MyApplication.exe"
KillProcDLL::KillProc "MyApplication.exe"
I also tried nsProcess plug-in and it also does not work.
nsProcess::_KillProcess "MyApplication.exe" $R0
It seems people have success with these plug-ins but I don't know why it's not working in my scenario unless it has something to do with background processes.
Any help would be appreciated.
None of the NSIS plug-ins I tried worked. They would all return no result (not even 0 or a negative number). I ended up just using the following command and it worked with no problems. It will briefly pop up a command window, but I am okay with this in my scenario:
ExecWait "TaskKill /IM MyApplication.exe /F"
Hope this helps someone else.
Without knowing exactly which NSIS version you are using nor if you are compiling a Unicode or ANSI installer it is a bit hard to say exactly what's going on.
The original version from the wiki only works on 32-bit processes and the hnedka version should support 64-bit processes as well.
If you are using the hnedka version and NSIS v2.x then you need to extract the plug-in from the ANSI folder to \NSIS\Plugins. If you are using NSIS v3 then you need to extract from the ANSI folder to \NSIS\Plugins\x86-ansi and from the Unicode folder to \NSIS\Plugins\x86-unicode.
I can confirm that that hnedka version works in NSIS v3. If $R0 is empty then perhaps you extracted the wrong plug-in .dll to the wrong folder.
Apparently you are trying to find and kill a x64 process which is not supported. You should check this link out
http://nsis.sourceforge.net/Processes_plug-in
Related
I have a custom bootstrapper (C# WPF) and it works well enough. If the installer gets run from the command line after it was installed, it brings up a window allowing the user to select if they want to modify, repair or uninstall. So far so good. Modify mode starts the UI which ends up calling Bootstrapper.Plan(LaunchAction.Modify). The problem is that if I call it from the launcher UI it immediately complains that a prior install requires a reboot.
I have not found any good examples on what this should do. Even the WiX mailing list came up blank.
Any ideas?
It would be helpful with the screenshot for that reboot message - just to get a feel for where it might be coming from and to get a literal string to search for. Did you have a look in the WiX source code yourself btw? (WiX 3.111 branch)
I started writing a lot of stuff about reboots. Not good. Maybe just some questions instead:
Does this happen every time you invoke modify and is it reproducible on more than one computer? Or maybe it is just Windows Update acting up on a problem computer?
I assume you have rebooted the computer where you see the problem and you see the problem again when you re-launch the bundle?
Do you schedule any reboots inside your MSI files during the initial installation?
Either using the ScheduleReboot action or a custom action which schedules a reboot with a call to MsiSetMode (for example)?
There is a long explanation here why such reboot-constructs cause problems, but that may be besides the point. Essentially badly configured reboot-constructs can trigger spontaneous, unexpected reboots without warning when packages are run in silent mode (plus other problems).
Could you try to run the test VBScript found in this answer: WiX behaving badly on XP machine with windows update issues in order to check if the script reports a reboot being necessary?
Other than that I guess you could try to run Burn yourself in debug mode (not sure how much plumbing that would be to get running) or perhaps first try a ProcMon.exe session to see if you can see something obvious. The latter should be quick to do?
There are some registry locations you can hunt down to see if you can figure out what triggered the reboot warning. Get-PendingReboot-Query. And a similar PowerShell script.
So in the end it was user error. :-( O well. I did learn a lot about how to figure out how Windows checks for the need to reboot etc.
The issue was simple in the end. During the modify run it was uninstalling, then reinstalling a number of services. The problem is that when it runs (seeing as you have to set it to repair to get it to work) it copies all the files again and the services were still running at the start of the install. The fix was to uninstall anything that might lock a file before the actual file copy starts and that solved the issue for me.
Thanks for your help guys, all the info helped me look in different directions until I found the issue. Awesome community as always!
I'm developing a windows application (using vb.net) that can install various versions of runtimes like vc++, Direct X, .net frameworks etc on a PC. My program must be able to to run the runtime installers (msi & exe) one at a time in the background and do the following:
1.Check weather the runtime is already (previously) installed or not.
2.Show the installation progress in a progress bar in the main form of my program.
3.And at last get the return code (exit code) from the installer to indicate weather the installation was successful or not.
What are the codes required to perform the above tasks?
Also I want to know what are all the possible return codes(values) an installer can return.
All of those redistributables might have different command line options, so it's not likely to be one answer for everything.
It's not clear how you can get the installation progress. It's almost certainly impossible or very difficult. You're asking how you can run a program that will "steal" the output of some other program, and in many cases that will be Windows Installer. If I had a program that fired off a Windows Form program, then you're asking "how can I get the content of that program and steal the output messages". That's not an install question, it's a Windows messaging/windows message loop question.
The detection methods used by those setups are coded internally (or configured as internal data), so you're also asking how the code in all those programs detects that the dependency isn't installed (on multiple OS versions and 32-bit and 64-bit), and some of that might be available on the web but it's unlikely that it is readily available for every redistributable.
You might also have an issue with EULAs. Some redistributables need a EULA to be accepted and might not install unless it's accepted, or some may have a command line option that includes something like (just an example) ACCEPTEULA=1.
Basically you should:
Find the command line options available for all those redistributables to see if they have an option that displays only progress, then let them show that.
Similarly, see if they have documentation that tells you if the exit code means success or not.
Don't bother trying to find all the detection methods for everything - just run the redist, and if the target is already installed it won't do anything.
Finally, you are re-inventing the wheel. WiX, the Bootstrap Manifest Generator, InstallShield, Advanced Installer (and so on) all provide bootstrapper programs that already do this as prerequisites for installing software. Nobody writes code to do this any more because there are existing solutions.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
1638 for already installed. 0 for successful installation. Yet mind 3010 which stands for success but pending reboot.
About showing progress in parent window .. this may be not a trivial task. Hopefully someone else can give you a hand with that.
I have a working WIX Bootstrapper that does install the software I need it to install. However On Windows 8 At least, there is a 16 minute period where it appears to do nothing. Looking at TaskManager, I see no processes taking resources from the Bootstrapper (that I can tell). For some reason about 15 minutes into it it will just finish the install:
[0E6C:0E90][2014-01-24T13:49:45]i299: Plan complete, result: 0x0
[0E6C:0E90][2014-01-24T13:49:45]i300: Apply begin
[0E04:0DD8][2014-01-24T14:05:35]i360: Creating a system restore point.
[0E04:0DD8][2014-01-24T14:05:50]i361: Created a system restore point.
Any ideas as to why this is taking so long, after the log says "Apply begin"?
Note: Behavior does not happen on XP or Vista, Or 7. I think it has something to do with "pausing" Windows updates during installs. Does anybody know anything about that?
Thanks.
This sounds like a timeout of some sort. I assume there are multiple MSI files, and some of them may be tagged with a launch condition (look in the LaunchCondition table) which disallows installation on Windows 8? Maybe worth a check at least. Try launching each MSI manually in sequence and see if you receive any error messages. There may also be missing runtimes such as .NET, C++, Crystal Reports or similar. Often the MSI will display an appropriate error message to tell you what is wrong.
In case you find nothing when launching each MSI, you should make verbose log files for all of them so there is something to work with for debugging. If you are unfamiliar with msiexec.exe (Windows Installer Command Line Interface), you can use the tool described in this thread: installation using msi.exec open help options every time . It should be easy to enable verbose logging using that tool.
Also check this thread: How to skip a bootstrapper or ignore fail in Windows 8?
And the documentation might be useful: http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/
I never could find a parameter or condition in my installer that would cause this. However the effect went away when I used insignia to sign my wix projects (MSIs and a bootstraper). Prior to that I had been using the signtool by itself to do the signing.
I have just completed my GTK#/Mono application and am preparing to build an installer. (I'm working in .NET Framework 3.5 and the Most recent stable Mono, 2.6.7, which installs Gtk 2.10.0) I would prefer to make the install as local as possible and not force people to go installing GTK# for .NET on their own. I looked at the installer for banshee (http://banshee.fm) to guide me, and I got almost all of the way there. Unfortunately, the PNG resources I had embedded in my application were not loading.
After an hour or so of intimacy with procmon (http://sysinternals.com), I find that the file libpixbufloader-png.dll isn't being loaded. It's being searched for in only one place: c:\program files\GtkSharp\2.12\lib\gtk-2.0\2.10.0\loaders. If I create just that folder tree and stick the file there, it works.
It seems slightly insane that GTK#/GTK would only look in a single hardcoded location for this file -- not even in the folder the application is in. Can someone tell me if a) this is indeed expected behavior, and b) if there's anything I can do about it, short of having my installer make this path itself? I know I can also just spawn out the GTK# installer, but I was hoping to keep all the Mono/GTK stuff local to my installation, to avoid later confusions over versions, etc.
I think your installer needs to run this at the end:
C:\Program Files\GtkSharp\2.12\bin\gdk-pixbuf-query-loaders.exe
See the Wix for the official Gtk# installer here:
https://github.com/mono/gtk-sharp/blob/gtk-sharp-2-12-branch/msi/unmanaged/unmanaged.wxs
You don't have to call the .exe mentioned my jpobst, because you can enter relative paths into the gdk-pixbuf.loaders config file (btw as you see the paths are not hard coded).
I am using Installshield, and have had success in launching my exe install files (such as KLite) after all my files have transferred to their target destination.
My question is this:
I am currently able to launch all the install exe's necessary, but they all launch at the same time, which can be rather annoying and cluttering. I am using a "Custom Action" to launch each executable. I am trying different "In-Script Execution" properties to no avail. My "Return Processing" is set to Asynchronous(Waits for exit code), yet it still is giving me problems.
I'd like to have each one execute once the previous is completed.
Anyone have experience in this? It has to be possible...
Thanks,
-Kyle
You want Sync not ASync. BTW, I don't reccomend EXE CA's except in the rarest of situations. Primarily because they are out of process with very limited ability to report back success and 0 ability to write back to the Windows Installer Log and have very unprofessional flashing of DOS CMD windows.
Always try to use C++ / C# custom actions instead.
Also be sure to read the following:
Integration Hurdles for EXE Custom Actions
http://blogs.msdn.com/b/windows_installer_team/archive/2007/10/20/integration-hurdles-for-exe-custom-actions.aspx
If you must use an EXE be sure to use something like WiX QuiteCA ( you can wrap this up into a WiX merge module and consume it with your InstallShield Basic MSI project ) to help shield you from these problems and get improved logging.