从 ASP.NET 应用程序 (IIS 7,5) 中运行控制台应用程序 (.exe)
我在 Windows 2008 R2（.NET Framework 4.0、IIS 7.5）上有一个 ASP.NET 应用程序，我想在单击网页上的按钮时运行控制台应用程序。代码如下：
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);
}
当我从 Visual Studio 2010（及其内部 IIS）中运行 ASP.NET 应用程序时，控制台应用程序运行正常。但是，当我在 VS 2010 之外运行 ASP.NET 应用程序时，我没有出现错误，但控制台应用程序无法完成其工作（它必须在磁盘上创建一个 xml 文件）。 我认为问题在于 IIS 7.5 的配置，我不知道必须向哪个帐户授予对控制台应用程序中涉及的文件夹的访问权限。 在 IIS 7.5 中，我为特定用户 = 我的 Windows 帐户设置了物理路径凭据，但这并不能解决问题。 谢谢。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只是添加到其他 2 个答案 - 您真的需要从网络服务器运行 exe 吗？
我过去不得不这样做，而且它几乎总是最后的选择 - 它大大削弱了你的安全性（现在，有人在你的系统上运行可执行文件所要做的就是在你的代码中找到一个缺陷）并且有一个一大堆其他问题（网络服务器没有“登录”到服务器，因此它没有桌面，模拟对于 a$$ 来说是一个真正的痛苦才能正常工作（假设你要运行具有不同权限的可执行文件 。
如果有任何其他方法可以实现您的目标，
那么我们选择的一个选择是拥有一个带有 Web 服务器可以与之通信的新应用程序 按钮，WS 通过 WCF 调用我们的应用程序，并告诉它运行各种命令，这样，您就可以：
请注意，无论您如何执行此操作，如果有人恶意了解正在发生的情况并可以启动该过程，他们可能几乎可以零努力地对您进行 DoS - 确保此方法被严格锁定。
编辑：阅读了上面的评论后，我认为您遇到了“桌面”问题。从服务器启动可执行文件时，登录用户永远看不到该应用程序，因为登录用户的桌面无法从 IIS 访问，反之亦然。这与在 Windows 服务上使用 GUI 的问题非常相似。
这个 可能也有兴趣。
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:
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.
我看到的第一个问题是安全/文件访问。当从 VS 中运行时，服务器和客户端在您的凭据下是同一台计算机。当在测试/生产环境中运行时，服务器和客户端在物理上是不同的计算机，并且 IIS 将在受限权限下运行网站。因此，出于安全原因，IIS 很可能无法访问 D:... 处的文件。
下一期是从网站运行控制台应用程序。控制台是 UI 的另一种形式，就像 html 和 WPF 一样。就我个人而言，我不会从网络执行控制台（除非别无选择）。我会将 API 集成到 Web 应用程序中。 2 个 UI 共享相同的逻辑。
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.
ASP.NET Dev Server 在当前用户（就是您）的凭据下运行。
IIS 7.5 在应用程序池设置中指定的用户下运行 ASP.NET 应用程序 - 通常是 ApplicationPoolIdentity（在配置文件权限时，您可以将其称为用户“IIS AppPool\[ApplicationPoolName]”）。您还可以将其更改为“网络服务”（IIS 7.0 中的默认值）。
请检查为您的应用程序池配置了哪个身份，并授予该用户所需的权限。
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.