Mar*_*inL 5 c# console-application taskscheduler
我正在运行C＃Windows控制台应用程序，并通过Task Scheduler传递了几个参数。它全天运行，将其他应用程序创建的平面文件数据加载到SQL Server中。该程序间歇性地失败，并且我具有Try / Catch逻辑，该逻辑使用Console.WriteLine（）写入有关异常的信息。
因此，基本上我需要跟踪控制台输出的位置，以便可以采取措施消除间歇性故障。我在网上浏览了很多，认为这是诊断Task Scheduler计划的应用程序中的错误的相当普遍的要求。我的在线搜索显示了一些解决方案，但是当直接通过Task Scheduler运行ac＃控制台应用程序时，关于控制台输出的位置没有直接答案。
我看到的两个解决方法是：
（1）获取任务计划程序以运行Windows批处理脚本（.bat文件），而不是直接运行控制台应用程序（.exe文件）。在批处理脚本中，使用“>”或“ >>”将控制台输出重定向到平面文件（例如C：\ app \ myapp.exe arg1 arg2>“ C：\ log \ myapp_console_output.txt”）
（2）一个非常相似的解决方案是让Task Scheduler使用/ C选项运行Windows命令行cmd.exe，并将参数传递到cmd.exe中以运行我的控制台应用程序，并重定向控制台输出。例如：cmd.exe / C“ C：\ app \ myapp.exe” arg1 arg2>“ C：\ log \ myapp_console_output.txt”
尽管我承认上述变通办法很可能会帮助我捕获将来的故障，但并不能真正帮助我跟踪已发生的间歇性故障的输出。它们似乎也很杂乱，无法实现我认为是非常常见的标准要求。
任何人都可以确认直接通过Task Scheduler运行ac＃控制台应用程序时，控制台输出肯定不会保留在某处吗？
小智 -1
技术答案是任务计划程序应用程序在您可以轻松访问的单独桌面（会话零）上运行。曾经有一个弹出窗口可以让您访问，但它\xe2\x80\x99s已经很长时间不可用了。
\n在 Windows 会话 0 中，即使没有桌面，我也能够获取桌面，为什么？提供更多详细信息。
\n