我研究了 COM 服务器和 Windows 服务，但我不确定什么最适合我的目的或如何去做。我想要的是可以启动并运行无限时间的东西，它持有一个对象，以便其他进程或应用程序获取对该对象的引用（或向服务器发出请求）以修改或查询其状态。
服务器本质上是一个应用程序，它通过串行端口处理对设备的命令并维护设备的内部状态。
我现在有用 C# 编写的设备通信和持久性功能，它可以在每个进程的基础上创建和运行，但显然我希望它实例化一次并独立于其他进程运行。
我读过的 COM 教程只是让我感到困惑，因为我不完全确定这是否是我想要的，我希望有更多的 .Net 方式来做到这一点。
任何帮助将不胜感激！
这似乎很适合 Windows 服务。我应该说我不是.net 程序员，但我知道您可以使用.net 创建服务。只要您知道可以使用 .net 操作串行端口，就可以了。
-大学教师
您的要求有点矛盾——如果服务器必须无限期运行，无论是否有客户端要服务，并且必须在所有客户端之间共享进程，无论它们在哪个会话中运行，Windows 服务都是要走的路。
如果您希望服务器仅在有客户端时运行，并且可能（或不）希望这些客户端共享相同的服务器进程，COM Out Of Process Servers 可以是一个选项。
如果是 COM，则必须使用 DCOM 与服务器进程进行通信。对于服务，您可以使用 DCOM、命名管道、RPC 或其他一些 IPC 机制。
但是，如果您希望用 C# 编写服务器代码，那么 DCOM 似乎有点奇怪——可以用 C# 创建 DCOM 服务器，但这确实很尴尬。正如 Kevin 所说，WCF/WAS/Remoting 可能是更容易的选择。但请记住，与本机 COM 服务器或服务相比，这样的解决方案几乎必然具有显着更高的内存消耗开销。如果这个软件要安装在客户端机器上，我因此更喜欢本机解决方案。
您似乎在要求两件事-
Windows 服务是第一个很好的解决方案。Windows 服务充当自定义逻辑的应用程序宿主。它通过通用 UI 和 API 为您提供启动/停止和轻量级监控和配置功能。在 C# 中构建 Windows 服务很容易。从命令行、从应用程序、从 GUI 工具启动和停止 Windows 服务很容易。
将 WCF 视为主要的通信接口。WCF 可用于构造 Windows Service 公开的外部接口。如果您想从 .NET 或 HTTP 客户端（REST 或 SOAP）连接到应用程序（服务），那么 WCF 将为您工作。
COM .... 您在 COM 适合的位置遇到的困惑是由于 COM 将接口机制（IDispatch、IUnknown 等）与托管 + 生命周期模型（本地服务器、Inproc 服务器、远程服务器、根据要求自动启动等）。COM 中的托管和生命周期的东西是有效的，但它总是很苗条。很难知道哪些服务启动了，持续了多长时间。难以按需启动和停止。
在这种情况下，COM 与 WCF 一样，主要用作通信接口。如果您想使用基于组件的接口连接到服务，COM 可能是 Windows 服务托管的一个很好的补充。
COM 和 WCF（REST 或 SOAP）并不相互排斥，事实上许多应用程序都公开了多个接口。你可以选择做一个，或另一个，或两者兼而有之。没有错误的答案，这取决于您的要求。
如果我这样做，我将使用 Windows 服务，并且我将从该服务公开一个 COM 接口，如此处所述。生命周期和托管内容由 Windows 服务负责。然后可以通过 COM 访问该服务，这意味着通过几乎任何编程或脚本语言/环境。Javascript、VB6、Excel 或 OFFICE、Python、Perl 等。
我还考虑从服务中公开 WCF 接口。这也将允许任何 REST 客户端进行连接。将 WCF 视为无线电话，将 COM 视为固定电话。有时你只想要一个。有时你想要两者。
我会为此构建一个 Windows Communication Foundation (WCF) 服务，并使用许多可用的绑定之一来公开它。您可以通过 HTTP/SOAP、HTTP/REST、TCP/Binary、MSMQ 等从同一个服务公开它。如果您有 Windows 2008，则可以通过 Windows 激活服务 (WAS) 激活它。如果你有一些其他的 Windows 操作系统，你应该编写一个可以注册到服务控制管理器 (SCM) 的 Windows 服务。这里有很多选择，但我肯定倾向于使用 WCF 来创建您的服务。WCF 会为您处理很多“管道”。无需重新发明所有这些。希望这可以帮助。