当我写一个服务时，我把所有的服务逻辑都放在一个dll项目中，并创建了两个“主机”来调用这个dll，一个是Windows服务，另一个是命令行应用程序。

我使用命令行应用程序进行调试，并仅针对无法在命令行应用程序中重现的错误将调试器附加到实际服务。

如果您使用这种方法，请记住，您必须在实际服务中运行时测试所有代码，而命令行工具是一个很好的调试辅助工具，它是一个不同的环境，并且它的行为与实际服务不完全相同。

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

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

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

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

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

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

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

更新

这种方法是目前为止最简单的:

http://www.codeproject.com/KB/dotnet/DebugWinServices.aspx

我把最初的答案留给后人。

我的服务倾向于有一个封装定时器的类，因为我想让服务定期检查它是否有任何工作要做。

我们在服务启动期间更新类并调用StartEventLoop()。(这个类也可以很容易地从控制台应用程序中使用。)

这种设计的一个很好的副作用是，可以使用用来设置Timer的参数在服务实际开始工作之前有一个延迟，这样就有时间手动附加调试器。

p.s. .如何手动将调试器附加到正在运行的进程…?

using System;
using System.Threading;
using System.Configuration;    

public class ServiceEventHandler
{
    Timer _timer;
    public ServiceEventHandler()
    {
        // get configuration etc.
        _timer = new Timer(
            new TimerCallback(EventTimerCallback)
            , null
            , Timeout.Infinite
            , Timeout.Infinite);
    }

    private void EventTimerCallback(object state)
    {
        // do something
    }

    public void StartEventLoop()
    {
        // wait a minute, then run every 30 minutes
        _timer.Change(TimeSpan.Parse("00:01:00"), TimeSpan.Parse("00:30:00");
    }
}

我也曾经做过以下事情(在之前的回答中已经提到过，但是使用条件编译器[#if]标志来帮助避免它在发布构建中被触发)。

我不再这样做了，因为有时我们会忘记在发布中构建，并在客户端演示上运行的应用程序中出现调试器中断(尴尬!)

#if DEBUG
if (!System.Diagnostics.Debugger.IsAttached)
{
    System.Diagnostics.Debugger.Break();
}
#endif

使用Windows Service Template c#项目创建一个新的服务应用程序https://github.com/HarpyWar/windows-service-template

有控制台/服务模式自动检测，自动安装/卸载您的服务，包括几个最常用的功能。

第一行的Debugger.Break()怎么样?