Run console application (.exe) from within ASP.NET application (IIS 7,5)

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.

Solution 1

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.

Solution 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.

Solution 3

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.

Comments

[Antonache Radu]

The identity configured for my application pool is set to Custom User (= my windows account which is Administrator on the server and I gave him explicit permissions on the folders). I already tried with the user "IIS APPPOOL\DefaultAppPool" but nothing is changed. But I don't know what role play Physical Path Credential for my application (now is set to the same account as in application pool).

[Antonache Radu]

I use Form Authentication for my web app, and I set Physical Path Credentials (in IIS) to Specific User ( my windows account which is Administrator on the server). The thing that puzzles me is that in VS everything is ok, and I don't succed to set IIS 7.5 so that the application could launch succesfully the console application. I want to avoid to rewrite the console application in web application because (at least for me) it isn't so simple, that why I try to resolve the problem that way.

[Antonache Radu]

The thing that stares me, is that the console application run when I use VS to run the web application, and not when I went out of VS, using IIS. Thanks for your answer, I appreciate your point of view.

[Basic]

It's very likely that IIS is running the application - you just can't see it. What does the app do? Try creating a simple app yourself that just writes to a text file somewhere public

[Antonache Radu]

The console application create un xml file which contain the structure and content of a folder (which is made virtual directory). So I can see if the console app is running.I will try your suggestion to create a simple app. Thanks a lot.

[Jason Meckley]

encapsulate the "console" logic into an API and then reference the API in both the we and console. keeping the code DRY.

[Antonache Radu]

Thank you very much, I follow your advice and it very convenient.