Is it possible to run a .msi file using Java's ProcessBuilder?

[Eric Daly]

Hi,
I'm trying to create a Java app that can read in a file that contains a list of software programs and the command line arguments to install them silently. Then my app will run the programs and make sure nothing goes wrong. It's working so far, but now I'm trying to install an Windows installer called AppleApplicationSupport.msi, and my Java app is unable to run it... is there a way to do this, or do I need to somehow extract the .exe files from the .msi installers? Thanks.

[James Sabre]

Eric Daly wrote:
I'm trying to create a Java app that can read in a file that contains a list of software programs and the command line arguments to install them silently..

You had better start wearing fire proof underpants because this unsocial program is going to get you flamed by your customers.

[Paul Clapham]

Pretty much anything which can be run from a Windows command line can be run via ProcessBuilder. I expect that .MSI files can be run via the START command at the command line on most Windows boxes. But on Windows 7 you should expect a box to pop up and ask the user to authorize the installer to modify the computer, regardless of how "silent" the installation is otherwise.

[Rob Spoor]

The famous rundll32 command can also be used: rundll32 url.dll,FileProtocolHandler <MSI file>

[Paul Clapham]

Or (in Java 6 at least) you should be able to use Desktop.open() to run an MSI file.

[Eric Daly]

It's too bad there isn't more documentation (or there isn't adequate documentation, depending on how you look at it) on the ProcessBuilder class. In my opinion, there just isn't enough information, because I can't find any help anywhere with this other than trial and error, and asking other people based on their own experience. What does ProcessBuilder's start() method do exactly? It certainly won't run msi files, at least in my case:

                File tempDir = new File(workingDirectory);
		if (tempDir.exists()) {
			for (Program temp : programList) {
				temp.setCanonicalPath(workingDirectory);
			}
			try {
				for (Program installer : programList) {
					name = installer.getName();
					JOptionPane.showMessageDialog(null, installer.getCommandString());
					ProcessBuilder p = new ProcessBuilder(installer.getCommandList());
					Process proc = p.start();
					proc.waitFor();
					JOptionPane.showMessageDialog(null, "Successfully installed " + name);
				}
			}
			catch(Exception e) {
				JOptionPane.showMessageDialog(null, "Couldn't find " + name);
			}
		}
		else {
			JOptionPane.showMessageDialog(null, "Can't find Standard Software directory!");
		}

where the working directory is C:\Documents and Settings\Owner\Desktop\Standard Software\ (this does exist, and my program works with any program in there that is an exe extension)
Program is a class I wrote that contains information about a program, including a name, an ArrayList<String> containing each command to use to install it (which I just pass in to ProcessBuilder's constructor). I get this by calling getCommandList(). getCommandString() returns the full path and command arguments that it's going to try to install (which displays correctly for everything, but only proceeds to work correctly with an exe file). An exception is thrown whenever trying to execute an msi file using ProcessBuilder, and then my program tells me it couldn't find the program (which isn't necessarily true, but the program here assumes that is the case). proc.waitFor() is used for two reasons: the first is to wait for the program to actually finish before reporting that it successfully installed, and the other is so that I can check the return code of the program and report on that (not included in this code).

Anyway, I hope that's enough background and clarification to let you know that there isn't just a bug in the code or something (well at least I don't think there is). I'll have to research the Desktop.open() solution, and see if there's a way to check the return code in that case, etc. I don't know anything about using rundll32, so I can research that one too, but I was really hoping to not even have to do it the old way by using Process and getRuntime because ProcessBuilder is a lot easier to manage (or is it?). Again, just in case anyone can help me out with this, what does ProcessBuilder's start() method really do behind the scenes? Are there really resources out there that explain any of this?

[Paul Clapham]

Come on, there's a whole screen-full of documentation in the API before it even gets to telling you about what methods are available. However if you were expecting a tutorial about how it works in every single operating system, you're right, there isn't one.

For example in Windows it only runs an executable. That's an EXE file if you like. It doesn't act like a command shell (not for any operating system actually). That's why I mentioned the START command. (Not to be confused with the start() method.) There's also the cmd.exe executable for running a single command which you might type at the command line.

And everybody who tries to use this class should read When Runtime.exec() won't.

[Eric Daly]

Hah, well thanks for the advice. I wouldn't mind a tutorial... But maybe I should write one (once I get all these things straightened out of course). I'll have to check out that link, I've seen it before but never read through it. I'll definitely decide which approach to take, either by trying to use the start command (thanks for clearing that up) or using some other method in the case of msi files. I'll post my solution when I find it!

[Eric Daly]

I know it's been quite a while, but I wanted to post my solution to this problem. I needed to get this program working, so I whipped up a C++ program that basically just takes the command line arguments you pass into it, and executes them (assuming the first command is the fully qualified pathname to some type of executable file). This then worked for any type of file, including .msi. Then I realized that rundll32 does exactly the same thing (plus more), so I was just wasting time in C++. Anyway, all I had to do was this:

try {
    Runtime run = Runtime.getRuntime();
    run.exec("rundll32 SHELL32.DLL,ShellExec_RunDLL msiexec /qb /i C:\\flash_ie.msi REBOOT=ReallySuppress");
}
catch (Exception e) {
    e.printStackTrace();
}

And I found that tutorial I needed: http://www.rgagnon.com/javadetails/java-0014.html
I hope this helps anyone else who might be reading this.

[James Sabre]

Eric Daly wrote:I know it's been quite a while, but I wanted to post my solution to this problem. I needed to get this program working, so I whipped up a C++ program that basically just takes the command line arguments you pass into it, and executes them (assuming the first command is the fully qualified pathname to some type of executable file). This then worked for any type of file, including .msi. Then I realized that rundll32 does exactly the same thing (plus more), so I was just wasting time in C++. Anyway, all I had to do was this:

try {
    Runtime run = Runtime.getRuntime();
    run.exec("rundll32 SHELL32.DLL,ShellExec_RunDLL msiexec /qb /i C:\\flash_ie.msi REBOOT=ReallySuppress");
}
catch (Exception e) {
    e.printStackTrace();
}

This is heavily flawed. I contains at least 3 of the 'traps' detailed in the article cited by Paul. It may run the desired command but the Java is still flawed. And what's with that exception handling? That's the lazy man's approach - "I can't be bothered to work out the best way to handle any exception I get here so I will just catch them all, report them and then continue as if nothing had happened" .

And I found that tutorial I needed: http://www.rgagnon.com/javadetails/java-0014.html
I hope this helps anyone else who might be reading this.

I used to be a fan of "The Real Howto" but over the last couple of years I have seen the addition of some poor code. That 'tutorial' is downright dangerous because it exhibits almost all the traps detailed in the 'traps' article.