使用命名管道通过 NamedPipeWrapper 在 Winforms 和 Windows 服务应用程序之间进行通信

Question

I'm attempting to communicate between a winforms app and a windows service using NamedPipeWrapper ( https://github.com/acdvorak/named-pipe-wrapper ) and I' having trouble with the server side, which is the service.

The code is in there to recieve messages, however when the service is running normally, nothing happens and running through debug on VS tells me the code will never be reached. The only way i can have it work is ifi create a function that means the service is always continuously working:

        public NamedPipeServer<string> server = new NamedPipeServer<string>("NamedPipe");
        private readonly ISet<string> client = new HashSet<string>();

public WinService()
        {
            InitializeComponent();

            server.ClientConnected += OnClientConnected;
            server.ClientDisconnected += OnClientDisconnected;
            server.ClientMessage += OnClientMessage;
            server.Error += OnError;
            server.Start();
            while (KeepRunning)
            { }
            server.Stop();
        }

        private bool KeepRunning
        {
            get
            {
                if (sc.Status.ToString() == "Running")
                    return false;
                return true;
            }
        }

The example code on the github article shows this for a console application to keep it shutting down, but I'm worried it will stop the rest of the service running (I'm using a timer to trigger events).

Would this system cause the timer to stop running, and is there any method where i can keep the service waiting for a message from the named pipe without resorting to using this method? it seems to use a lot of memory with this method(~300mb), and some of the servers i'm planning on adding this to might not have that spare.

Answer 1

I'm attempting to communicate between a winforms app and a windows service using NamedPipeWrapper ( https://github.com/acdvorak/named-pipe-wrapper ) and I' having trouble with the server side, which is the service.

Debugging services while writing them is notoriously hard. The way they have to be registered and launched via the service System. The need to manually attach the debugger. The part where they can not display a UI since Vista .

Some people have taken to doing the Service debugging and Development in a console application. Console has no bagage that makes simulating the Service environment hard, and you got a way to output debug messages. Of course you could also get away from Services entirely, using something like the TaskSheduler. It has all of the powers and then some, but none of the issues. Even Microsoft has transitioned stuff out of services over into that.

Answer 2

For this package, a windows service dosent appear to work as the "Server" side of the code, but having the winforms app as the server and the service as the client will work.