开发 C# 长时间运行的处理器应用程序的最佳方法
我有几个不同的 C# Worker 应用程序，它们运行各种连续任务：从队列发送电子邮件、将新订单从网站数据库导入到订单数据库、进行数据库备份和恢复、为 OLTP 运行数据处理 -> OLAP 和其他相关任务。 之前，我将它们发布为 Windows 服务，但目前我将它们发布为常规控制台应用程序。 它们都基于我创建的通用任务运行器框架，我对此感到满意，但是我不确定部署这些类型的应用程序的最佳方法是什么。 我喜欢控制台版本，因为它快速且简单，并且可以快速查看程序活动和输出。 缺点是工作计算机上有多个控制台屏幕正在运行，而且会变得混乱。 另一方面，服务方法似乎需要很长时间才能部署，我必须通过事件日志才能查看消息。 对此有哪些经验/评论？
I have several different c# worker applications that run various continuous tasks: sending emails from queue, importing new orders from website database to orders database, making database backups and restores, running data processing for OLTP -> OLAP, and other related tasks. Before, I released these as windows services, but currently I release them as regular console applications. They are all based on a common task runner framework I created, and I am happy with that, however I am not sure what is the best way to deploy these types of applications. I like the console version because it is quick and easy, and it is possible to quickly see program activity and output. The downside is that the worker computer has several console screens running and it gets messy. On the other hand the service method seems to take to long to deploy and I have to go through event logs to see messages. What are some experiences/comments on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我们经常使用 Windows 服务作为后台进程。 我不喜欢命令行应用程序，因为您需要登录服务器才能运行它们。 服务始终在后台运行（假设它们是自动启动的）。 使用 Windows 中的 sc.exe 命令行工具安装它们也很简单。 与 installutil.exe 等臃肿软件相比，我更喜欢它。 当然 installutil 可以做更多的事情，但我不需要它所做的事情。 我只想注册我的服务。
我们还创建了一个基础架构，其中有一个通用服务 .exe，它根据接口定义加载 .DLL，因此添加新“服务”就像放入新 DLL 并重新启动服务主机一样简单。
然而，我们开始放弃服务。 我们遇到的问题是它们锁定了 DLL（出于明显的原因），因此升级它们很痛苦。 我们需要停止、升级然后重新启动。 不难，但需要额外的步骤。 相反，我们正在转向 ASP.NET 应用程序中的特殊“页面”，这些应用程序运行我们需要完成的实际后台作业。 仍然有一个服务，但它所做的只是调用 asp.net 页面，因此它不会锁定我们的任何 DLL。 然后我们可以替换 ASP.NET bin 目录中的 DLL，并启动应用程序域重启的正常 ASP.NET 规则。
We regularly use windows services as the background processes. I don't like command-line apps as you need to be logged into the server for them to run. Services run in the background all the time (assuming they're auto-start). They're also trivial to install w/the sc.exe command-line tool that's in windows. I like it better than the bloat-ware that is installutil.exe. Of course installutil does more, but I don't need what it does. I just want to register my service.
We've also created a infrastructure where we have a generic service .exe that loads .DLLs based on an interface definition, so adding a new "service" is as simple as dropping in a new DLL and restarting the service host.
However, we started to move away from services. The problem we have with them is that they lock up the DLLs (for obvious reasons) so it's a pain to upgrade them. We need to stop, upgrade and then restart. Not hard, but additional steps. Instead we're moving to special "pages" in our asp.net apps that run the actual background jobs we need done. There's still a service, but all it does it invoke the asp.net pages so it doesn't lock up any of our DLLs. Then we can replace the DLLs in the asp.net bin directory and normal asp.net rules for app-domain restart kick in.
我将投票给 Windows 服务。 管理这些控制台应用程序将变得非常痛苦。
Windows 服务部署很简单：初始安装后，您只需将其关闭并执行 XCOPY。 无需运行任何复杂的安装程序。 第一次只是半复杂，即使如此，它也只是
将服务配置为在域帐户下运行，以获得最佳的安全性和与其他计算机最简单的互操作性。
使用事件日志（包含错误、警告和信息）的组合来获取重要通知，并将详细日志记录转储到文本文件。
I'm going to vote for Windows Services. It's going to get to be a real pain managing those console applications.
Windows Service deployment is easy: after the initial install, you just turn them off and do an XCOPY. No need to run any complicated installers. It's only semi-complicated the first time, and even then it's just
Configre the services to run under a domain account for the best security and easiest interop with other machines.
Use a combination of event logs (with Error, Warning, and Information) for important notifications, and just dump verbose logging to a text file.
为什么不充分利用世界上最好的东西并使用类似的东西：
http://topshelf-project.com/
它将允许您以命令行或 Windows 方式运行程序服务。
Why not get the best of all worlds and use something like:
http://topshelf-project.com/
It will allow you to run your program as command line or a windows service.
我不确定这是否适用于您的应用程序，但是当我有一些不依赖于用户输入的控制台应用程序或者它们是那种只完成其工作并退出的应用程序时，我在虚拟机上运行此类程序服务器，这样我工作时就不会看到屏幕弹出，而且虚拟服务器很容易创建和重新启动。
I'm not sure if this applies to your applications or not, but when I have some console applications that are not dependent on user input or they are the kind of applications that just do their job and quit, I run such programs on a virtual server, this way I don't see a screen popping up when I'm working, and virtual servers are easy to create and restart.
几年前我曾做过一些有类似问题的工作。 从逻辑上讲，我需要一项服务，但有时我需要了解正在发生的事情，而且通常我想要历史记录。 所以我开发了一个服务来完成这项工作，任何时候它想要记录，它都会调用它的订阅者（作为观察者模式实现）。
该服务注册了它自己的数据记录器（写入数据库），并且在运行时，用户可以运行一个 GUI，该 GUI 使用远程处理连接到该服务，成为实时侦听器！
I worked on something a few years ago that had similar issues. Logically I needed a service, but sometimes I needed to see what was going on and generally I wanted a history. So I developed a service which did the work, any time it wanted to log, it called to it's subscribers (implemented as an observer pattern).
The service registered it's own data logger (writing to a database) and at run time, the user could run a GUI which connected to the service using remoting to become a live listener!
Windows 服务将是一个不错的选择，无论您是否关闭当前会话，它都会在后台运行，也可以将其配置为在服务器上执行补丁更新时 Windows 重新启动后自动启动。 您可以将重要消息记录到事件查看器或数据库表中。
Windows Service would be a good choice, it runs in the background no matter if you close current session, also you can configure it to start automatically after windows restart when performing a patches update on the server. You can log important messages to event viewer or database table.
对于这样的事情，执行此操作的标准方法是使用 Windows 服务。 您希望该服务在网络帐户上运行，因此不需要登录用户。
For a thing like this, the standard way of doing it is with Windows services. You want the service to run on the network account so it won't require a logged in user.
我喜欢控制台应用程序方法。 我通常会进行一些设置，这样我就可以通过像 -unattended 这样的开关来抑制控制台屏幕。
I like the console app approach. I typically have things set up so I can pass a switch like -unattended that suppresses the console screen.