Run console application (.exe) from within ASP.NET

Question

I have an ASP.NET application on Windows 2008 R2 (.NET Framework 4.0, IIS 7.5) and I want to run a console application when I click a button on a web page. Here is the code:

protected void btnUpdate_Click(object sender, EventArgs e)
    {
        string fileLocation = @"D:\DTDocs\App_Code\LoadDTDocsXML.exe";
        ProcessStartInfo oStartInfo = new ProcessStartInfo();
        oStartInfo.FileName = fileLocation;
        oStartInfo.UseShellExecute = false;
        Process.Start(oStartInfo);
}

When I run ASP.NET application from within Visual Studio 2010 (with its internal IIS), the console application run Ok. But when I run the ASP.NET application outside the VS 2010, I haven't an error but the console application doesn't make his job (it must create an xml file on the disk). I think the problem is the configuration of IIS 7.5, I don't know exact to which account I must give access rights to the folders involved in my console application. In IIS 7.5, I set Physical Path Credential for Specific User = my windows account, but that not solve the problem. Thanks.

Answer 1

the first problem I see is security/file access. when running from within VS the server and client are the same machine under your credentials. when run in testing/production environment the server and client are physically different machines and IIS will run the website under restricted permissions. therefore there is a very good chance that IIS cannot access the file at D:... because of security.

the next issue is running a console app from the website. console is another form of UI just like html and a WPF. personally I wouldn't execute the console from the web (unless there was no other choice). I would integrate the API into the web application. 2 UIs sharing the same logic.

Answer 2

ASP.NET Dev Server runs under credentials of current user (it's you). IIS 7.5 runs ASP.NET applications under user specified in application pool settings -- usually ApplicationPoolIdentity (to which you can refer as user "IIS AppPool\[ApplicationPoolName]", when configuring file permissions). You can also change it to "Network Service" (Default value in IIS 7.0).

Please check, which identity is configured for your application pool, and give this user required permissions.

Answer 3

Just to add to the other 2 answers - Do you really need to run an exe from your webserver?

I've had to do it in the past and it's almost always the option of last resort - It weakens your security considerably (Now all someone has to do to run executables on your system is find a single flaw in your code) and has a whole host of other problems (the webserver isn't "logged on" to the server so it doesn't have a desktop, impersonation is a real pain in the a$$ to get working properly (assuming you're going to run the executable with different permissions to the webserver), etc.

If there's any other way to accomplish your goal, it'll almost certainly be simpler.

An option we went for was to have a new app with a WCF endpoint that the webserver can communicate with. So, when someone pushes the button, the WS call's our app via WCF and tells it to run various commands. This way, you've got:

• Clean seperation between web and console code.
• A dodgy console app won't take down the webserver & vice-versa
• If the console app is long-running, this allows you to stagger your releases for website/console app so that you don't kill the app mid-execution just because you need up upodate some CSS and publish.
• Huge security benefits - web server can't run executables even if compromised.
• The WCF app will be able to closely examine requests to decide if they're valid before execution.

Be aware that however you do it, if someone malicious works out what's going on and can kick off the process, they could probably DoS you with almost zero effort - Make sure that this method is locked down TIGHT.

Edit: having read your comments above, I think you're hitting the "desktop" issue. When launching an executable from the server, the app will never be visible to the logged on user as the logged on user's desktop isn't accessible from IIS and vice-versa. This is very similar to the issue of having a GUI on a windows service.

This may also be of interest.