Jenkins调用C#控制台程序启动交互模式WCF服务异常问题

启动失败是两个独立问题叠加导致的：

1. 以Windows服务模式安装的Jenkins默认运行在Session 0非交互会话，它拉起的所有子进程都会继承非会话属性，.NET运行时检测到进程处于Session 0时，会直接将Environment.UserInteractive返回为false。你的WCF服务判断该值为false后就会自动走Windows服务启动分支，检测到自身未通过installutil安装就直接退出，这就是那个安装提示的来源。
2. Jenkins默认会在构建任务结束后，自动终止当前任务拉起的所有关联子进程，你之前加的BUILD_ID=dontKillMe配置位置错误，没有生效。

不需要把WCF安装为Windows服务，按优先级从高到低尝试以下方案即可：

方案1：调整Jenkins启动方式，消除会话隔离（最推荐，和本地调试环境完全一致） #

• 不要将Jenkins注册为Windows服务运行，直接在你日常登录的普通用户桌面会话中，通过命令java -jar jenkins.war启动Jenkins主程序。此时Jenkins本身运行在交互会话中，拉起的所有子进程都会继承交互会话属性，Environment.UserInteractive会正常返回true，和你在Visual Studio里调试的运行环境没有区别。
• 如果需要Jenkins开机自启，直接给当前用户配置登录触发的启动项，运行上述java命令即可，不需要注册系统服务。

方案2：保留Jenkins服务模式，绕开检测+修正防杀配置 #

如果必须用Windows服务方式跑Jenkins，按以下两点调整：

• 修正进程防杀配置：不要给WCF服务进程单独加BUILD_ID=dontKillMe环境变量，要在Jenkins构建步骤的执行上下文里提前设置这个变量——批处理步骤先执行set BUILD_ID=dontKillMe，PowerShell步骤先执行$env:BUILD_ID="dontKillMe"，再调用你的控制台启动程序，这样整个进程树都会被Jenkins跳过终止逻辑。
• 绕开UserInteractive的误判：不要依赖Environment.UserInteractive判断运行模式，给WCF服务增加明确的启动参数，比如启动时传入--interactive，WCF收到这个参数就强制走交互模式启动逻辑，完全跳过系统属性判断，从根源避免Session 0导致的分支误判。对应启动代码修改为：

myProcess.StartInfo.Arguments = "--interactive";

注意：如果你的WCF交互模式需要弹出UI窗口、和桌面交互，Session 0下是无法实现的；如果只是需要WCF后台驻留监听端口、处理请求，就算在Session 0里只要走对交互启动逻辑，服务功能完全正常，不需要桌面权限。

方案3：通过计划任务中转拉起进程 #

如果上述方案都不适用，可以不在代码里直接通过Process.Start拉起WCF，改为调用Windows系统的schtasks命令，创建一个运行在当前登录交互用户会话下的临时计划任务，通过任务触发WCF启动。这种方式拉起的WCF进程运行在正常交互会话中，UserInteractive返回值符合预期，也不会被Jenkins识别为构建子进程杀掉。示例命令如下：

schtasks /create /tn "TempStartWcf" /tr "完整路径\MyServiceExe.exe" /sc once /st 00:00 /ru 登录用户名 /rp 用户密码 /it
schtasks /run /tn "TempStartWcf"
schtasks /delete /tn "TempStartWcf" /f

命令中/it参数的作用就是强制任务以交互模式运行在用户已登录的会话中。

• 配置myProcess.StartInfo.UseShellExecute = false不生效，是因为该参数仅控制进程启动是否走Windows Shell文件关联逻辑，不会修改进程所属的会话属性。
• 给WCF子进程加BUILD_ID环境变量不生效，是因为Jenkins扫描待终止进程时，是从构建步骤的根进程开始遍历整个进程树，子进程上单独配置的环境变量不会影响Jenkins的匹配逻辑。
• 提示需要用installutil安装服务，不是系统强制要求必须安装Windows服务，是WCF程序自身的判断逻辑走到了Windows服务启动分支抛出的提示，只要绕开该分支判断即可，不需要真的执行服务安装。

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