跨系统进程生成和交互
我正在开发一个软件，它在远程系统上生成短暂的进程来运行一些代码（主要是 SerialPort IO），这些代码可能会或可能不会与生成的应用程序交互（但应该假设它会），然后将根据命令终止。
生成这样的远程进程的最佳方法是什么（PSExec？WMI？也许是System.Diagnostics.Process？） 生成进程后，我如何告诉它订阅其主机？ 对于通信过程中基于事件/消息的基本框架，SO 社区会推荐什么？ WCF 是否适合这项任务？ 远程处理会更容易吗？ 我在这里有什么选择？
I've got a piece of software i'm working on that spawns short lived processes on remote systems to run some code (mostly SerialPort IO) that may or may not interact with the spawning application (but it should be assumed it will), and will then terminate on command.
What is the best way to spawn a remote process like this (PSExec? WMI? System.Diagnostics.Process perhaps?) After the processes is spawned how can i tell it to subscribe to it's host? What would the SO community reccommend for a basic event/message based framework for the communication process? Is WCF well suited to the task? would Remoting be easier? What are my options here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为 System.Diagnostics.Process 不允许在远程系统上启动进程。 因此，WMI 或 shell 等 psexec 可能是您唯一的选择。
关于订阅/交互选项，是的，WCF 是最佳选择。 避免远程处理：它对一般情况没有任何好处，不再得到增强，并且由于多种原因而被弃用，取而代之的是 WCF（基本上分布式对象由于版本控制和状态考虑而变得令人头疼；消息传递通常是如果我没记错的话，远程处理也没有安全性）。 为了进行此设置，当父进程生成远程进程时，它可以将 URL 作为命令行参数传递。 父级在该 URL 上托管 WCF 服务。 现在，如果生成的进程需要与父进程通信/订阅父进程，它只需连接到给定的 URL。 如果父进程需要启动通信，则使 WCF 服务双工，或者让生成的进程托管其自己的 WCF 服务，并通过父进程的服务告诉父进程 URL。
I don't think System.Diagnostics.Process allows launching a process on a remote system. So WMI or shelling to something like psexec may be your only options here.
Regarding subscription/interaction options, yes, WCF is the way to go. Avoid Remoting: it offers no benefits for the general case, is no longer being enhanced, and is deprecated in favour of WCF for a variety of reasons (basically distributed objects become a pain in the neck due to versioning and state considerations; messaging is usually easier to set up, understand and maintain. Also remoting had no security if I remember rightly). For setting this up, when the parent process spawns the remote process, it could pass a URL as a command line argument. The parent hosts a WCF service on that URL. Now if the spawned process needs to communicate back to / subscribe to the parent process, it just connects to the URL it was given. If the parent needs to initiate communication, then make the WCF service duplex, or have the spawned process host its own WCF service, and tell the parent the URL via the parent's service.