0

I am looking for a simple way to send messages between a Winforms Application and a Windows Service. The service will be run under LocalSystem so will be able to install updates to my Winforms App. The app is run in very locked down environments where port will be blocked and the file system is not reliable enough to use it for logging. I have tried using Named Pipes but i could not get this to work. I want to keep it simple so was thinking of trying Memory Mapped Files?

I only want to pass simple strings back and forth between the app and service, e.g.

APP-> Service [Please download this file http... and place it here C:\Program Files...]

Service->APP [0% downloaded]

Service->APP [1% downloaded]

etc..

Service->APP [Update Complete/Failed]

I cant seem to find a good example of how this can be achieved? Is memory mapped files the best way to go? If so, where do i start?! I have been reading through this Post but i cannot seem to make sense of it, its been a long day! I want everything to be in memory, unlike in this example. Can anyone help?

cjsmith87
  • 13
  • 3
  • Using pipes is the best way to go IMO (especially when sending/receiving instructions like you describe). You should look more into that. MMFs have bigger overhead since they need to access the disk. – Visual Vincent Sep 11 '18 at 15:57
  • Thanks, I tried using a nuget package called NamedPipeWrapper but despite their sample project of 2 simple win forms apps working, I could not get it to talk between a service and a desktop app. Any ideas where I might have been going wrong? Daft question I know but I am clutching at straws now! – cjsmith87 Sep 11 '18 at 16:01
  • I think you should rather have asked a question about why your pipe-code didn't work, as that is more on-topic here than your current question (which is more opinion-based than fact-based). – Visual Vincent Sep 11 '18 at 16:05
  • You shouldn't need a NuGet package though, as both anonymous and named pipes are natively supported by the .NET Framework: https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-use-named-pipes-for-network-interprocess-communication – Visual Vincent Sep 11 '18 at 16:07
  • Apparently I was mistaken: Named pipes use files as well. I still think it's a better choice than MMF, though. :) – Visual Vincent Sep 11 '18 at 16:10
  • Thanks for the link Vincent, I cant seem to work out how to send and receive messages asynchronously. I want to start a client and server in the background, both sides should have have a post message method and an event that fires when a message is received so it can be passed to the main thread. I might just be being thick here... – cjsmith87 Sep 11 '18 at 16:27
  • Both the `NamedPipeServerStream` and `NamedPipeClientStream` have methods for performing asynchronous reading and writing (for instance[`WriteAsync()`](https://learn.microsoft.com/en-us/dotnet/api/system.io.stream.writeasync?view=netframework-4.7.2#System_IO_Stream_WriteAsync_System_Byte___System_Int32_System_Int32_)). Check the [documentation](https://learn.microsoft.com/en-us/dotnet/api/system.io.pipes.namedpipeclientstream#methods) for more; it is your best friend in cases like this. – Visual Vincent Sep 11 '18 at 16:34
  • As for events, since the data is streamed you have to create some kind of data structure that can be passed between your applications. A common method is to _prefix_ the data with its length, so the other end knows how many bytes to read ([this answer of mine](https://stackoverflow.com/a/37352525) describes how that works, it was written for TCP but the concept is the same). Be aware that one call to `Write()` _usually_ requires more than one call to `Read()` to get all the data. This is why you need this so-called _length prefixing_. – Visual Vincent Sep 11 '18 at 16:40
  • If you don't want to implement length prefixing by yourself you can take a look at [_Binary Serialization_](https://www.codeproject.com/Articles/254617/Serialization-Part-I-Binary-Serialization), which will take care of that part for you (instead of a `FileStream` you use your pipe). The only backside is that the data will get a bit bigger than if you implement it on your own (unless this is a problem for your application, you'll be fine). – Visual Vincent Sep 11 '18 at 16:48

0 Answers0