Windows服务和应用程序之间共享内存,什么是最简单的?

发布于 2024-12-10 07:18:43 字数 713 浏览 0 评论 0原文

我需要我的服务更新共享内存中的字段,以便客户端应用程序读取和显示。我发现我当前的解决方案由于会话 0 隔离而无效。

我已经重命名了全局命名空间中的互斥体,这修复了该元素,但看起来 dll 似乎无法在会话之间共享,尽管会话 0 隔离的一种解决方案是:

“为任何命名对象显式选择 Local\ 或 Global\ 命名空间,例如 服务提供的事件或映射内存。”

我不知道 dll 的哪一部分可以归类为命名对象,并且需要很长时间才能重新安装并逐步检查它。

我看到了代码我不想创建一个接触磁盘的文件,因为我想象 dll 的共享部分可以工作吗

public ref class ServerGUIBridge
{
public:
#pragma data_seg(".sdata")
    static int commonIntShouldBeGlobal = 0;
    static bool hasBeenInitializedMakeMeGlobal = false;
#pragma data_seg()
#pragma comment(linker, "/section:.sdata,rws")

?使用 .NET 2.0 所以不需要请WCF。

I need my Service to update fields in shared memory for a client application to read and display. I've found my current solution to be ineffective because of Session 0 Isolation.

I've renamed the mutexes in the Global namespace which fixes that element but it doesn't look as though the dll will be amenable to sharing between sessions despite one solution to Session 0 Isolation being:

"Explicitly choose either the Local\ or Global\ namespace for any named objects, such as
events or mapped memory that the service makes available."

I don't know which part of the dll can be classified as a named object and it will take too long to keep re-installing and stepping through it to check.

I saw the code volumes for named channels and was put off. I don't want to create a file that touches the disk as I imagine is required of the memoryMappedFile solution. Can shared sections of dlls be made to work? Otherwise what is easiest?

public ref class ServerGUIBridge
{
public:
#pragma data_seg(".sdata")
    static int commonIntShouldBeGlobal = 0;
    static bool hasBeenInitializedMakeMeGlobal = false;
#pragma data_seg()
#pragma comment(linker, "/section:.sdata,rws")

I'm using .NET 2.0 so no WCF please.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

溇涏 2024-12-17 07:18:43

我建议使用命名管道:这样您就可以在两个进程之间进行适当的受控隔离。共享 DLL 听起来充满了危险。

命名管道在 MSDN 上有记录:http://msdn.microsoft.com/en -us/library/aa365590.aspx

以及一篇看起来很有用的 .NET 2.0 文章:http://www.switchonthecode.com/tutorials/interprocess-communication -using-named-pipes-in-csharp

(请记住,.NET 3.5 及更高版本有一个 NetNamedPipeBinding 类 [ http://msdn.microsoft.com/en-us/library/system .servicemodel.netnamedpipebinding.aspx ] 这是 WCF 的一部分)

I'd suggest named pipes: then you have proper controlled isolation between the two processes. Sharing DLLs sounds like it's fraught with danger.

Named pipes are documented on MSDN here: http://msdn.microsoft.com/en-us/library/aa365590.aspx

and a useful looking .NET 2.0 article is here: http://www.switchonthecode.com/tutorials/interprocess-communication-using-named-pipes-in-csharp

(Bear in mind that .NET 3.5 and above has a NetNamedPipeBinding class [ http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx ] that's part of WCF)

微暖i 2024-12-17 07:18:43

所有.NET框架版本都具有远程处理功能。它允许调用另一个应用程序域中的方法,这些方法可以位于单独的进程中。有关示例和用法,请参阅 MSDN:http://msdn .microsoft.com/en-us/library/kwdt6w2k(v=VS.80).aspx

All .NET framework version have Remoting feature. It allows to call methods in another appdomain which can be in separate processes. See MSDN for samples and usage: http://msdn.microsoft.com/en-us/library/kwdt6w2k(v=VS.80).aspx

云裳 2024-12-17 07:18:43

IPC 的一种经常被忽视的方法是写入注册表。对于我建议分享的两个 POD 成员来说,这将是理想的解决方案。 IPC、MSDN 和注册表

One often overlooked method of IPC is writing to the registry. For the two POD members I propose to share this would be the ideal solution. IPC, MSDN, and the registry

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文