Process.Start 不起作用答案

【问题标题】：Process.Start won't workProcess.Start 不起作用
【发布时间】：2014-10-20 02:30:23
【问题描述】：

我正在尝试从网页的后端代码/应用程序池启动一个进程。此过程将启动我自己构建的应用程序。

由于某种原因，该进程仅在我从 VS2013 启动时才有效/运行......当我从 IIS(7.5) 本身启动它时它永远不会工作。

我在 Windows 7 机器上（IIS 主机和应用程序位置），并且我已将我的网站设置为只能通过内部网络访问。

这是代码，后面是配置/尝试解决问题：

protected void btn_DoIt_Click(object sender, EventArgs e)
{
    string file_text = this.txt_Urls.Text;

    if (!String.IsNullOrWhiteSpace(file_text))
        File.WriteAllText(ConfigurationManager.AppSettings["filePath"], file_text);

    ProcessStartInfo inf = new ProcessStartInfo();

    SecureString ss = GetSecureString("SomePassword");
    inf.FileName = @"........\bin\Release\SomeExecutable.exe";
    inf.Arguments = ConfigurationManager.AppSettings["filePath"];
    inf.UserName = "SomeUserName";
    inf.Password = ss;
    inf.UseShellExecute = false;
    //launch desktop app, but don't close it in case we want to see the results!
    try
    {
        Process.Start(inf);
    }
    catch(Exception ex)
    {
        this.txt_Urls.Text = ex.Message;
    }

    this.txt_Urls.Enabled = false;
    this.btn_DoIt.Enabled = false;
    this.txt_Urls.Text = "Entries received and process started. Check local machine for status update, or use refresh below.";
}

以下是我尝试解决的问题：

确保执行程序集是使用 AnyCPU 而不是 x86
确保运行应用程序的 AppPool 也在与指定的 ProcessStartInfo 相同的帐户 (SomeUsername) 下运行。
确保特定用户帐户对可执行文件的文件夹具有完全访问权限。
确保 IIS_USR 具有对可执行文件文件夹的完全访问权限。
在实施这些修复程序时多次重新启动应用程序池和 IIS 本身

我现在不知道为什么这根本不会启动应用程序...当我第一次查看事件日志时，我看到应用程序会立即死亡，代码为 1000:KERNELBASE.dll，这让我在 AnyCPU 配置上而不是 X86 修复上...修复了事件日志条目，但应用程序仍然无法启动（任务管理器中没有出现任何内容），并且我在事件日志中没有错误...

如果有人能帮我解决这个问题，我将不胜感激。这将允许我通过网络上的任何设备（手机、平板电脑、笔记本电脑等）在我的主计算机上执行特定任务，而无需在我的主 PC 前...

更新

对我的 OP 的评论和@Bradley Uffner 的最终回答实际上解决了问题：我的“应用程序”实际上是一个带有 UI 的桌面应用程序，为了运行该应用程序，IIS 需要能够访问桌面和 UI，就像坐在 PC 前的人一样。当然不是这样，因为 IIS 仅作为服务帐户运行，它不应该在后台启动 UI 程序是有道理的。另请参阅他的答案以了解解决此问题的一种方法。

【问题讨论】：

使用高权限帐户运行 IIS 很危险。考虑让您的 Web 应用程序设置一个标志（例如，在数据库中、通过发布到消息队列、通过创建文件等）来导致进程开始运行。
我不担心谁运行它（仅限本地网络），或者它的作用（应用程序做了一些完全不影响 PC 的特定操作），或者传递给它的东西因为应用程序是安全构建的（只有特定的东西，以特定的格式，导致它做任何事情）......否则，它只是退出并记录和无效的尝试......真的不担心它，只是希望它运行。
如果黑客能够弄清楚如何访问本地网络中的端口 80，则可以利用 IIS 的提升权限以及 IIS 中恰好存在的任何安全漏洞来获得所有权限，如果运行 IIS 的用户，包括访问文件和执行任意代码。如果那不担心你，你很好。这会让我担心。
@EricJ。就像我说的...我的系统和我的网络受到很好的保护。我明白你在说什么，但我不担心有人访问端口 80，因为我没有使用端口 80，我正在使用的端口被以下任何外部呼叫阻止：我的网关，我的调制解调器路由器，我的内部路由器、我的本地 (win) 防火墙和位于 (win) 顶部的我的第 3 方防火墙。端口 80 也是如此......如果这能让你平静一点；）
您的代码将应用程序称为“桌面应用程序”，这是否意味着它具有用户界面？ IIS 作为服务帐户运行，无法访问桌面“上下文”，它将无法显示 UI，并且程序可能会立即失败。不幸的是，如果是这种情况，我真的想不出一个好的解决方案。

标签： c# asp.net iis

【解决方案1】：

您最好的选择可能是尝试将其写成 2 个部分。将命令发布到文本文件（或数据库，或其他一些持久存储）的网站，以及定期轮询该文件（数据库等）以进行更改并执行这些命令的桌面应用程序。您可以写出整个命令行，包括 exe 路径命令参数和开关。

这是我真正能想到的唯一方法，允许像 IIS 这样的服务应用程序执行需要登录用户的桌面上下文的应用程序。

【讨论】：

到目前为止，这是最有意义的。不只是重写代码，以便当前在桌面应用程序内完成的实际工作现在也直接在 ASP.Net 页面的后端运行......这实际上可以解决所有问题。然后，该场景中的权限只需访问我正在与之交互的文件夹，并且不必知道或弄乱 Win Desktop 上下文，因为没有调用 UI。我最终会看到我想要实现的内容，但是是的......现在这很有意义（以及您对 OP 的评论），这实际上解释了它失败的原因。

【解决方案2】：

您应该为正在运行的应用程序池分配一个具有足够高权限的技术用户。默认情况下，应用程序池使用具有非常低权限的 ApplicationPoolIdentity 身份运行。

【讨论】：