.Net 中的端口读取应用程序，这是更好的 Windows 服务或 Windows 应用程序答案

【问题标题】：Port reading application in .Net which is better Windows service or Windows application.Net 中的端口读取应用程序，这是更好的 Windows 服务或 Windows 应用程序
【发布时间】：2017-10-17 06:13:31
【问题描述】：

我正在.Net 中编写一个 TCP/IP 端口读取应用程序以从 IOT 设备读取数据，目前它作为 Windows 应用程序运行。我想让它成为 Windows 服务，有更好的选择吗？我想读取 24/7 端口。还有比 Windows 服务更好的选择吗？

【问题讨论】：

如果你想让它成为一个windows服务，那么这显然是你更好的选择。这里没有可应用的客观衡量标准，当然不是您目前提供的详细程度。
如果需要网络资源，则在 LocalSystem 或 NetworkService 下运行 Windows 服务。如果容量很大或设备数量更多，则在两者之间有一个数据集成/消息通道，例如 Kafka，以确保您不会丢失数据。
对于开发和调试 windows 应用程序更好，但对于发布我会选择 windows 服务 - 显然，如果你对生产环境中的控制台窗口很好，win 应用程序就可以了。

标签： c# .net vb.net windows-services iot

【解决方案1】：

如果您希望能够在没有用户登录的情况下运行程序，那么 Windows 服务是您的最佳选择。如果你想要一些图形用户界面，一个普通的应用程序更有用。

作为侧节点，您可以在作为服务启动和作为应用程序启动之间更改带有调试标志的应用程序。为您的应用程序添加一个服务类，并为您的自定义代码添加另一个类。该服务还将调用 Sample 类。然后，如果您在 Program.cs 中添加预编译器#if DEBUG，则可以在调试期间在使用每个之间切换

    public static void Main()
    {
#if DEBUG
        SampleClass sc = new SampleClass();
        sc.Start();
#else
        ServiceBase[] servicesToRun = new ServiceBase[]
        {
            new SampleService ()
        };
        ServiceBase.Run(servicesToRun);
#endif
    }

然后您还可以为每种构建类型添加不同的输出代码

    public static void WriteLog(string message, LogLevel logLevel)
    {
#if DEBUG
            Console.WriteLine(message);
#else
            Trace.Write ($"{DateTime.Now:dd.MM.yyyy HH:mm:ss.fff} {message}");
#endif
    }

然后，如果您启动应用程序，请在构建和调试之间进行选择。但是您只能通过这种方式将发布构建安装为服务。

【讨论】：

我喜欢这个设计。建议在作为服务运行时登录到Windows Event Log。这对于 Windows 服务来说是非常常见的做法，并且可以使生产服务的故障排除变得更加容易。例如，如果Exception 被捕获，您可以将其作为错误写入EventLog，并带有完整的堆栈跟踪[如果需要]。

【解决方案2】：

是的，Windows 服务就可以了。我想使用一个名为TopShelve 的小库来制作服务/控制台应用程序。然后我会添加NancyFx 以公开服务及其数据（或从共享数据库中读取）。

您还问是否有“更好”的方法。您可能会争辩说轮询所有 IoT 设备不是一个好主意（您可能会使用太多资源）。让他们将他们的阅读（当他们认为合适时）广播到消息队列（这些小设备中的大多数都喜欢使用MQTT）。那么您的应用程序应该只订阅所需的队列并在需要时处理数据。

【讨论】：

【解决方案3】：

选择其中一个可能有多种原因，但这里有一些建议可能会帮助您做出决定。

您提到了 24/7，因此 Windows 服务应该是您毫无疑问的选择。但是你需要考虑以下

确保将所有可配置的值放入配置文件中。例如侦听端口、间隔或任何其他您可能想要更改而无需重新编译/重新部署的东西，因为您不会有 UI 来控制它。

您还可以将所有这些设置存储在一个 json 或 xml 文件中，您可以为其创建一个单独的 UI 来管理该设置文件，而 Windows 服务工作只是从这些设置中读取。

更进一步，您还可以使用正在启动的 Web api 端点将代码添加到您的 Windows 服务，该端点响应休息请求以操作您可能想要交付给您的 Windows 服务的服务配置和/或操作/命令。这将允许 Windows 服务在有或没有用户会话的情况下在后台运行，也可以通过休息调用从单独的机器控制。

但这些只是一些想法，你做多少取决于你需要做多少。

【讨论】：

【解决方案4】：

应用程序是您在桌面上与之交互的程序。

Microsoft Windows 服务专门设计用于解决 24/7 服务正常运行时间问题并摆脱面向 GUI 的表单应用程序， C# 提供了如何开发 Windows 服务的非常好的和易于使用的示例。与错误记录系统一起，它可以成为您解决方案的组成部分。为了使您的 Windows 服务对调试器友好，您可以将其放在

Topshelf 技术。我在我的经验中使用它，它大大减少了开发/调试时间。

【讨论】：

【解决方案5】：

我没有在 .NET 中编写服务的经验，而且我一直觉得调试起来很棘手。

您要求“更好的选项”，这是一个替代选项，但是否更好将在很大程度上取决于您的要求：那么，作为替代方案，您是否考虑过任务调度程序？

我在 .NET 中有许多命令行应用程序，我可以在 Visual Studio 中运行和调试它们，然后在需要定期运行时由任务调度程序调用。如果您想使用任务调度程序，那么只需确保它不需要任何用户交互（也不需要 gui），但同样的限制也适用于服务。如果它是用于长时间运行的应用程序（您的应用程序似乎是），那么您可以使用任务调度程序将其设置为运行，如果您愿意，如果它仍然没有运行，您可以使用任务管理器定期重新启动它。

服务更适合某些事情。当然，它们比任务调度程序更容易停止（因为对于任务调度程序，您必须在任务管理器中找到进程才能杀死它）。

可能值得考虑为什么要让它作为 Windows 服务运行。如果它只是在您的机器启动时设置它运行的一种方式，那么计划任务将同样好。如果是因为您想要编写 Windows 服务的经验，那么将其作为 Windows 服务进行。等等

【讨论】：

【解决方案6】：

为什么要重建轮子？你可以使用WinDivert：

允许用户模式应用程序捕获/修改/丢弃发送到/来自 Windows 网络堆栈的网络数据包

和

可用于实现用户模式的数据包过滤器、数据包嗅探器、防火墙、NAT、VPN、隧道应用等

您可能会在 C# 或 .NET 中使用它

【讨论】：

他需要“在.Net中编写一个TCP/IP端口读取应用程序来读取来自IOT设备的数据”，运行WinDivert有助于在TCP/IP网络流中实时交互，他也可以使用自定义过滤器检测 IOT 网络数据包并在触发时读取/重构相关数据 ...