C# Process.Start（“IIS管理器.lnk”）失败，返回“0”；系统找不到指定的文件"；

我正在通过

Process.Start

启动路径

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk

，但由于

系统找不到指定的文件而失败

该链接显示在
目录上，因此它存在

可以吗

注:


通过迭代
开始菜单
目录，自动发现路径
我可以通过浏览器和命令行启动它

澄清：


代码如下：

public void Execute（）{Process.Start（_shortcut.FullName）；}

_快捷方式的类型为FileInfo

_Exists为true，因此可以找到该文件
将_shortcut.FullName替换为显式路径@“C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk”具有相同的效果
这是一个使用Caliburn和MEF的WPF应用程序
以管理员身份运行具有相同的效果

另一方面，这似乎是可行的：

    [Fact]
    public void TestIisManager()
    {
        var path = new FileInfo(@"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk");
        Process.Start(path.FullName);
    }

它似乎确实有点“环境”为基础

第二项澄清：


它似乎可以在Windows7x86中工作，但不能在Windows7x64中工作
这有点像黑客，但试着像这样启动它：

string path = @"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk";
Process.Start("cmd.exe", String.Format("/k \"\"{0}\"\"",path));

注意保存路径中的空格所需的双引号。
这样，您可能会看到更精确的错误消息和/或随后在命令环境中查看路径的错误。
这实际上可能与您的情况无关，但您可以使用

Process.Start("inetmgr.exe")

如果要继续使用快捷方式，如果使用
ProcessStartInfo
启动进程并将
ProcessStartInfo.UseShellExecute
设置为
true
可以确保您正在STA线程中尝试此操作吗？如果以下示例成功，您可以看到单元状态是否存在问题：

using System;
using System.Diagnostics;

public class Program
{
    // make sure to call Process.Start from an STA thread
    [STAThread]
    static void Main(string[] args)
    {
        Process.Start(@"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk");
    }
}

Process.Start
调用
ShellExecute
在引擎盖下运行传递的文件。如Raymond Chen所述，shell函数需要STA线程：


发现了问题

WPF应用程序编译为x86（所有其他DLL编译为AnyCPU），在64位机器中启动某些可执行文件或链接时失败

将“平台目标”更改为AnyCPU可以解决这个问题。
我最近遇到了这个问题。基于Windows窗体的解决方案，VS2013，x64计算机。Process.Start（）无法通过.lnk文件启动应用程序。使用process explorer，.lnk文件中指定的目标似乎无法正确解析为c:\program files（x86）。。。而不是c:\程序文件。。。我听从了布鲁诺的建议，但我的目标已经被标记为“AnyCPU”

经过一番深思熟虑之后，发现在VS11+中有一个新的编译器标志，名为“preference 32-bit”，它是默认选中的。这迫使EXE输出为32位，即使我的操作系统为64位，平台设置为AnyCPU。在我取消检查并重新编译后，问题得到了解决

更多阅读请访问：
这对我很有效，因此我认为这是您的环境的问题。您是否使用任何进一步的选项来处理.Start（）
？您正在使用完整路径吗？你是以其他用户的身份运行你的应用程序吗？这对我来说很好。让我们看一下代码中调用
Process.Start（）
的部分。您可以使用Sysinternals中的Process Monitor来找出流程实际查找该文件的位置。我认为，默认情况下，ProcessStartInfo.UseShellExecute设置为true，因为其他链接似乎可以工作。但我还是试过了，它仍然抛出了异常，所以我不得不禁用“首选32位”选项。见Sat Thiru的回答。