Question

我在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应用程序时，控制台应用程序运行Ok。但是当我在VS 2010之外运行ASP.NET应用程序时，我没有错误，但控制台应用程序没有完成他的工作（它必须在磁盘上创建一个xml文件）。我认为问题是IIS 7.5的配置，我不知道具体到哪个帐户我必须授予我的控制台应用程序中涉及的文件夹的访问权限。在IIS 7.5中，我为特定用户 =我的Windows帐户设置物理路径凭据，但这不能解决问题。感谢。

Answer 1

只是添加其他2个答案 - 你真的需要从你的网络服务器运行exe吗？

我过去必须这样做，它几乎总是最后的选择 - 它大大削弱了你的安全性（现在所有人必须做的就是在你的系统上运行可执行文件，你的代码中发现了一个缺陷）并且还有许多其他问题（网络服务器没有“登录”到服务器上，所以它没有桌面，模拟是一个真正痛苦的a $$才能正常工作（假设你要去运行具有不同权限的可执行文件到网络服务器等）

如果还有其他方法可以实现你的目标，那几乎肯定会更简单。

我们选择的一个选项是拥有一个新的应用程序，其中包含Web服务器可以与之通信的WCF端点。因此，当有人按下按钮时，WS调用我们的应用程序通过WCF并告诉它运行各种命令。这样，你就得到了：

清除网页和控制台代码之间的分离。
一个狡猾的控制台应用程序不会删除网络服务器＆amp;反之亦然
如果控制台应用程序长时间运行，这允许您错开网站/控制台应用程序的发布，这样您就不会因为需要更新某些CSS并发布而终止执行中的应用程序。
巨大的安全优势 - 即使受到破坏，Web服务器也无法运行可执行文件。
WCF应用程序将能够仔细检查请求，以确定它们在执行前是否有效。

请注意，无论你是这么做的，如果有人恶意解决了正在发生的事情并且可以启动这个过程，他们可能几乎没有努力让你这么做 - 确保这个方法被锁定了。

编辑：看过上面的评论，我认为你正在遇到“桌面”问题。从服务器启动可执行文件时，登录用户将永远不会看到该应用程序，因为无法从IIS访问登录用户的桌面，反之亦然。这与在Windows服务上使用GUI的问题非常相似。

This也可能是有意义的。

Answer 2

ASP.NET Dev Server在当前用户的凭据下运行（就是您）。 IIS 7.5在应用程序池设置中指定的用户下运行ASP.NET应用程序 - 通常是ApplicationPoolIdentity（在配置文件权限时，您可以将其称为用户“IIS AppPool \ [ApplicationPoolName]”）。您还可以将其更改为“网络服务”（IIS 7.0中的默认值）。

请检查为您的应用程序池配置了哪个标识，并为该用户授予所需权限。

Answer 3

我看到的第一个问题是安全/文件访问。当从VS内部运行时，服务器和客户端是您的凭据下的同一台机器。当在测试/生产环境中运行时，服务器和客户端在物理上是不同的机器，IIS将在受限制的权限下运行网站。因此，由于安全性，IIS很有可能无法访问D：...文件。

下一期是从网站上运行一个控制台应用程序。控制台是另一种形式的UI，就像html和WPF一样。我个人不会从网上执行控制台（除非别无选择）。我会将API集成到Web应用程序中。 2个UI共享相同的逻辑。

从ASP.NET应用程序（IIS 7,5）中运行控制台应用程序（.exe）

3 个答案: