我正在使用一个应用程序，并且我能够使 C# 脚本在这个环境中运行。我可以将任何类型的 DLL 导入此环境。我的问题是我想启用这些脚本之间的通信。由于环境是受控的，我无法访问应用程序的源代码，我不知道如何做到这一点。
我尝试过的事情：
文件 I/O：只需将我希望每个人都读取的消息写入 .txt 文件并让另一个人读取它。问题是我需要这个脚本运行得非常快，这占用了太多时间。
nServiceBus：我试过这个，但我无法让它在我正在处理的环境中工作。我不是说做不到，只是说做不到。
有谁知道这样做的简单方法，也很快？
您的进程间通信方法应取决于处理每条消息的重要性。
例如，如果进程 A 告诉进程 B，例如，向您的 IT 员工发送一封电子邮件，说服务器已关闭，这非常重要。
但是，如果您正在流式传输音频，则单个消息（数据包）对应用程序的性能并不重要，并且可以被丢弃。
如果是前者，您应该考虑使用数据库等持久存储来存储消息，并让每个进程轮询数据库以检索自己的消息。这样，如果一个进程暂时终止或失去与其他进程的通信，它将能够在再次启动时检索它丢失的任何消息。
即使在同一个进程中，您也可以使用一种进程间通信形式。将您的脚本视为单独的进程，并以这种方式进行通信。
在这种情况下，命名管道可能是一个不错的选择。它们非常快，并且在 .NET 3.5 中相当容易使用。
或者，如果脚本加载到单个 AppDomain 中，您可以使用静态类或单例作为通信服务。但是，如果脚本被单独加载，这可能是不可能的。
答案很简单；
由于您可以将任何 DLL 导入脚本，因此您可以创建一个自定义 DLL，该 DLL 将以您希望的任何方式实现进程之间的通信：共享内存、命名管道、TCP/UDP。
好吧，不知道你的环境细节，我能提供的东西不多。您正在使用术语“C# 脚本”...我不确定这意味着什么，因为 C# 通常是一种编译语言。
如果您使用的是普通 C#，您是否使用命名管道研究过 WCF？如果您的程序集在同一台物理机器上运行，您应该能够轻松快速地创建一些使用命名管道绑定托管的 WCF 服务。命名管道在本地上下文中提供了一种简单、高效、快速的消息传输机制。WCF 本身非常易于使用，并且是 .NET 框架的本机组件。
由于您已经准备好文件 I/O，因此您可以通过将其放在 RAM 磁盘上来获得足够的速度。如果您今天正在轮询更改，FileSystemWatcher可以帮助您的通信更具响应性。
您可以使用PipeStream。这比磁盘 IO 快，因为它们是使用主内存完成的。
另一种简单的方法是在预定义的端口上打开一个 TCP 套接字，从另一个进程连接到它并以这种方式进行通信。
XMPP/Jabber 是另一种方法，看看jabber.net。