Damn GUI, Always Crashing My Parties

Problem: getting a specific executable to run (executable resides on a server) through an ASP page.

Details: The windows scripting host object on a server can create a shell object with which you can run command line commands. The code is straight forward and easy:

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run YOUR_COMMAND

The problem is that while the Run method works fine on your local machine, it's not so hot when you're trying to fire it off from an ASP page. This is because the user going to the ASP page will not see whatever is going on on the server. But what about a self-contained command line executable? That works fairly well provided there's no GUI.

When there is a GUI, nothing works. This is because the IIS process fires off the executable (successfully too) under its account but then there is no user interaction. The process starts but then just sits there doing nothing. Not so great.

All this works when you run a vbs script locally though because then the application starts and the user (you) can interact with the GUI on its local machine. So, what's the solution?

Solution: Since the GUI problem is not circumventable, we put the onus of action on the user. Stick a VBS file with your WshShell.Run directive (and whatever else you might want to do) on a network drive accessible to your user(s). Then, when you need your executable to do its thing, give a link directly to the vbs file on the network. The user will click on the link, run the vbs file, and then be on his merry way. You can even pop up a

MsgBox("Who's your daddy?!")

when the script is done. You can also pass arguments, conveniently, to the vbs file in your Run directive so a limited amount of information can persist.

Limitations: It's still a hacky work around. Since you're breaking the web-flow of the pages, the user can not be automagically directed to the next page in his web browser.

Don't try this at home: "Ah ha," you might be thinking, "you're not a 1337 h5x0r like 3y3 4M. Why don't you just create a non-GUI exe to call the other exe? For that matter why not just call a bat or vbs file in from WshShell.Run?" That, my grasshopper, doesn't work either, because either way that GUIed up executable is going to run. And when it does, it's still going to hang.

Recap: ASP-->VBS file on network-->executable-->MsgBox-->User goes back to ASP.