views:

272

answers:

6

We have an internal page that I want to use to run an executable that updates some files on the server. In other words, rather than logging in to the server every time I need to manually run this executable, I would like to run it from the browser. The executable is self-contained on the server and does not interact with the user.

Here is my code:

    try
    {
        System.Diagnostics.Process p = new System.Diagnostics.Process();
        p.StartInfo.UseShellExecute = false;
        p.StartInfo.FileName = Server.MapPath(@"\iPhoneXMLCreator.exe");
        p.StartInfo.WorkingDirectory = Server.MapPath(@"\");
        p.StartInfo.RedirectStandardOutput = false;

        p.Start();
        p.WaitForExit();
        lblResult.Text = "Success!";
    }
    catch (Exception ex)
    {
        lblResult.Text = "Oops, there was a problem.<br><Br>" + ex.Message;
    }

When I run it, the process shows up in Task Manager, but then exits within a few seconds without updating the files it is supposed to. There are no arguments to be passed, just a simple executable. Any ideas?

+5  A: 

I would start by checking to see if the account which runs the web application has the appropriate permissions.

Kevin
Wouldn't the process fail if it didn't have IO acccess? All the permissions are set properly.
TruthStands
Access to the exe yes, but if the files to update are in a different directory that could cause problems.
Kevin
Just gave Everyone full permissions and still nada.
TruthStands
I haven't tried this, but you may want to look here:http://www.daniweb.com/forums/thread132773.html
Kevin
I'll keep looking too
Kevin
+1  A: 

Most likely this is a permissions issue. Since it's the Asp.Net runtime that is executing this program, you need to ensure that the user account that the Asp.Net runtime uses has access to this executable, and to modify any resources (files, databases, etc) that get modified by the executable.

You can do this via impersonation, or by granting rights tot he appropriate accounts. The proper approach is to use impersonation.

http://msdn.microsoft.com/en-us/library/xh507fc5.aspx

David Stratton
haha, I though I typed quickly! Good to see that a few of us have been burned with the ASPNET account/permissions before :)
curtisk
+1  A: 

Does the executable file run and process the XML when you run it manually on the server logged in as yourself?

Then it may be a simple permissions issue, since unless you are impersonating ...it's probably trying to run the exe under the ASPNET machine account, which most likely doesn't have rights to the folder the XML is in. Just a thought based on the info you provided.

curtisk
Yes, it also runs as a scheduled process using the NETWORKSERVICE account. This is on IIS7, which I believe uses NETWORKSERVICE as the default user for IIS, right?
TruthStands
A: 

Rather than playing with website permissions for the Exe, one workaround that uses a level of indirection and puts a buffer between your web site and the Exe is to simply set a flag value into a text file on the web server when the Page representing the Exe is hit.

Set up a scheduled job on the server to check for that flag value every X hours, or minutes, or whenever and if the flag is seen, run the executable. Reset the flag/file when done. This opens up the possibility to check the flag via a webservice or other mechanisms, such that the target Exe doesn't even need to be on the same web server machine.

This is only viable if the exe does not need to run immediately when the page is hit.

John K
+1  A: 
JMarsch
Didn't get any clear help from ProcMon, and no output using the 2nd idea.
TruthStands
What do you mean by no clear help? Did you find your process in ProcMon? Did it catch anything for your exe? Does the exe normally output anything (like even if it is successful? It's weird that it didn't capture any console output at all. Not many clues with this problem, huh? Have you tried outputing the mapped paths to make sure that they are right?
JMarsch
A: 

Ok, figured it out. It was a data access issue. The .config file for the .exe had an invalid database connection string. Why it would work when logged in, I'm not sure, but it works now.

TruthStands