我正在运行C＃windows控制台应用程序并通过任务计划程序传递几个参数。它整天运行将其他应用程序创建的平面文件数据加载到SQL Server中。程序间歇性地失败，我有Try / Catch逻辑，使用Console.WriteLine（）写入有关异常的信息。
所以基本上我需要追踪控制台输出的位置，以便我可以采取措施消除间歇性故障。我已经仔细研究过在线认为这对于诊断任务计划程序预定应用程序的错误是一个相当普遍的要求。我的在线搜索已经揭示了一些解决方案，但没有直接回答在通过任务计划程序直接运行c＃控制台应用程序时控制台输出的位置。
我看到的两个解决方法是：
（1）获取Task Scheduler以运行Windows批处理脚本（.bat文件），而不是直接运行控制台应用程序（.exe文件）。在批处理脚本中使用＆＃34;＆gt;＆＃34;或＆＃34;＆gt;＆gt;＆＃34;将控制台输出重定向到平面文件（例如C：\ app \ myapp.exe arg1 arg2＆gt;＆＃34; C：\ log \ myapp_console_output.txt＆＃34;）
（2）一个非常类似的解决方案是让Task Scheduler使用/ C选项运行windows命令行cmd.exe并将参数传递给cmd.exe以运行我的控制台应用程序并重定向控制台输出。例如就像是： cmd.exe / C＆＃34; C：\ app \ myapp.exe＆＃34; arg1 arg2＆gt; ＆＃34; C：\日志\ myapp_console_output.txt＆＃34;
虽然我承认上述解决方法可能有助于我捕捉未来的失败，但它并没有真正帮助我追踪已经发生的间歇性失败的输出。他们似乎也很混乱，以实现我认为是一个非常常见的标准要求。
任何人都可以确认在通过任务计划程序直接运行c＃控制台应用程序时，确实没有保留控制台输出吗？