我也认为为正常执行和作为服务提供一个单独的“版本”是可行的，但真的需要为此目的专门提供一个单独的命令行开关吗?

你就不能这样做吗:

public static int Main(string[] args)
{
  if (!Environment.UserInteractive)
  {
    // Startup as service.
  }
  else
  {
    // Startup as application
  }
}

这将有“好处”，你可以通过双击启动你的应用程序(好吧，如果你真的需要的话)，你可以在Visual Studio中点击F5(不需要修改项目设置，包括/控制台选项)。

严格来说，是环境。UserInteractive检查是否为当前窗口站设置了WSF_VISIBLE标志，但是除了作为(非交互式)服务运行之外，还有其他原因它将返回false吗?

您有两个选项来进行调试。

创建一个日志文件:我个人更喜欢一个单独的日志文件，比如文本文件，而不是使用应用程序日志或事件日志。但是这将花费你大量的时间，因为它仍然很难找出准确的错误位置 将应用程序转换为控制台应用程序:这将使你能够在VS中使用所有的调试工具。

请参考我为这个主题创建的这篇博客文章。

对于常规的小程序，我做了一个非常简单的技巧来轻松调试我的服务:

在服务启动时，我检查命令行参数“/debug”。如果使用此参数调用服务，我不会执行通常的服务启动，而是启动所有侦听器，并只显示一个消息框“调试正在进行中，按ok结束”。

因此，如果我的服务以通常的方式启动，它将作为服务启动，如果它以命令行参数/调试启动，它将像正常程序一样工作。

在VS中，我将添加/debug作为调试参数，并直接启动服务程序。

通过这种方式，我可以轻松地调试大多数小型问题。当然，有些东西仍然需要作为服务进行调试，但对于99%来说，这已经足够了。

您也可以通过命令提示符(sc.exe)启动服务。

就我个人而言，我会在调试阶段将代码作为独立程序运行，当大多数错误被解决后，再改为作为服务运行。

我认为这取决于你使用的操作系统，Vista很难附加到服务，因为会话之间的分离。

我过去使用的两个选项是:

Use GFlags (in the Debugging Tools for Windows) to setup a permanent debugger for a process. This exists in the "Image File Execution Options" registry key and is incredibly useful. I think you'll need to tweak the Service settings to enable "Interact with Desktop". I use this for all types of debugging, not just services. The other option, is to separate the code a bit, so that the service part is interchangable with a normal app startup. That way, you can use a simple command line flag, and launch as a process (rather than a Service), which makes it much easier to debug.

希望这能有所帮助。

最好的选择是使用“系统”。诊断的名称空间。

将代码包含在if else块中，用于调试模式和发布模式，如下所示，在visual studio中切换调试和发布模式。

#if DEBUG  // for debug mode
       **Debugger.Launch();**  //debugger will hit here
       foreach (var job in JobFactory.GetJobs())
            {
                //do something 
            }

#else    // for release mode
      **Debugger.Launch();**  //debugger will hit here
     // write code here to do something in Release mode.

#endif