ASP.NET Core Windows服务无法调用.NET Core进程的原因排查

让我来帮你梳理一下这个问题的核心原因，以及为什么换成.NET Framework的EXE就能正常运行：

1. 权限不足是头号问题 #

你的ScanClient.dll里尝试操作C:\Users\Mary\Desktop\mary.txt这个路径，但Windows服务默认是用Local System账户运行的——这个系统级账户没有访问普通用户（Mary）专属桌面目录的权限，桌面文件夹属于用户私有空间，Local System无权访问。

而.NET Framework的EXE能正常运行，大概率是因为你测试时给服务配置了有权限的账户（比如Mary本人的账户），或者EXE的权限逻辑在服务环境下适配性更好，但核心矛盾还是Local System的权限限制。

另外你设置了RedirectStandardError = false，导致进程报错时你看不到任何错误日志，这也阻碍了你直接定位问题。

2. Console.ReadLine()在服务环境下会彻底卡住进程 #

Windows服务运行在无交互的系统会话里，没有真实的控制台窗口可以接收输入。你的ScanClient里调用了Console.ReadLine()，这会让进程一直死等输入，但服务环境根本没有输入源，进程直接被挂起，看起来就像是启动失败了。

3. .NET Core进程的环境变量差异 #

Windows服务的环境变量和普通用户会话不一样，比如PATH里可能没包含dotnet运行时的安装路径，导致服务进程找不到dotnet命令来启动ScanClient.dll。而.NET Framework的EXE要么是自包含的，要么系统已经全局注册了运行时，不需要额外调用dotnet命令，所以不会遇到这个问题。

快速修复建议 #

针对这些问题，你可以按以下步骤逐一排查：

• 更换文件操作路径：不要碰用户桌面的文件，改用服务有权限访问的公共目录，比如C:\ProgramData\YourApp，或者给Local System账户手动授权访问目标文件夹。
• 删掉Console.ReadLine()：服务环境不需要控制台交互，去掉这个等待输入的代码，让进程能正常执行完毕。
• 指定dotnet的完整路径：启动进程时直接写dotnet.exe的绝对路径，比如C:\Program Files\dotnet\dotnet.exe，避免服务环境找不到命令。
• 修改服务运行账户：把Windows服务的运行账户从Local System改成Mary账户（或其他有权限的账户），这样就能访问Mary的桌面了，但注意这会带来一定安全风险。
• 临时启用错误重定向：把RedirectStandardError = true，然后读取process.StandardError的内容，这样就能看到进程启动失败的具体报错信息，方便精准排查。

内容的提问来源于stack exchange，提问作者 mary