1

Ok, long story short I have a Windows service that handles Win32_VolumeChangeEvent and logs USB disk device arrivals to the Event Log and to a SQL database. An additional component to this is a hidden UI (WinForms) which loads in the user session at login - this pops up a message box reminding users of company policy about USB keys etc. AFAIK, this was the best way to go since services can no longer run in interactive mode.

Anywho... architecturally, v1 of this little thing ran with the UI component handling WndProc messages for device insertion, then passed the device identifier through IPC (named pipes) to the service which would handle WMI methods / EventLog writing (as not all users have local admin rights). This had the downside of the UI element being process killed and no longer detecting device insertions.

So, current version is that the service handles Win32_VolumeChangeEvents and gets the needed details from the device, then logs to EventLog and SQL. All is outstanding and works perfectly. Except now I'm wondering what the best way to trigger the UI into displaying the popup is.

I've researched around Google and here, looking for ideas about eventing over IPC, so I can just subscribe to an event from the UI component and fire it within the service, but I'm not finding much that jumps out as being helpful. I'm also constrained to .net2, so WCF is out of the picture (although I'm not afraid of p/invoke if you want to go that way).

So. How would you do it? Links, thoughts, ramblings, pseudocode, actual code... all is appreciated. I'm trying to stick to what I believe is best practice, although I also think programming is a bit of an art form and my best practice may be someone else's horror story.

So SO - what would you do? Let me know if I need to clarify :)

dotalchemy
  • 2,459
  • 19
  • 24
  • 1
    This would be relatively easy with WCF. Why are you constrained to .NET 2? You do know that .NET 3.0 and 3.5 are both supersets of .NET 2, not really separate versions, and don't change the core assemblies? – Chris Dickson Feb 08 '11 at 22:59
  • We don't have good client side coverage of .net 3 installs, whereas we have almost complete coverage of .net 2 installs. Pushing .net3 isn't really an option at the moment. – dotalchemy Feb 08 '11 at 23:24

2 Answers2

3

Back in the bad old days of Windows API programming, we'd sometimes use RegisterWindowMessage to register a unique message ID that (presumably) only our window knew how to handle. We could then trigger that window from another application by calling PostMessage with a window handle of HWND_BROADCAST, and the msg parameter being that unique message value. That works great if everything you want to share between the processes can fit into two DWORD values (wparam and lparam). Sharing more data can be done if you allocate global memory and pass a reference as one of the parameters.

That should still be possible with .NET. Certainly there's no trouble calling PostMessage. As for handling the message in the UI code, you have to override the Form's WndProc. See How do I send/receive windows messages between VB6 and c#? for an example.

You could do something with named events, although that would only notify the UI that some change had occurred. It wouldn't actually tell you what happened. I suppose, if there's only a small set of possible events, you could have multiple events, but that gets complicated pretty quickly.

You could go the named event route and use shared memory (memory mapped file) to share the state.

Or, you could set up sockets, named pipes, TcpListener/TcpClient, or even a UdpClient. All should work, with varying degrees of complexity and/or reliability.

Community
  • 1
  • 1
Jim Mischel
  • 131,090
  • 20
  • 188
  • 351
  • 1
    Good options. Sadly, PostMessage et al won't cross the Session0 boundary and is subject to all kinds of Windows asshattery when it comes to sending messages between levels. I shall investigate the named events and sockets again. Marked both answers up for the moment and will accept after further lookery. – dotalchemy Feb 09 '11 at 04:22
  • 1
    You gave me a lot of good things to think about. Ultimately, I took it back to basics and capture WndProc in the UI (like I did in v1) with a timestamp so as to avoid multiple popups when Windows does its little message flood thing and implemented them essentially as two separate applications. It serves its purpose. Still, you took me on an awesome journey this afternoon, playing with different ideas and looking at different code. Thanks for the suggestion! – dotalchemy Feb 09 '11 at 05:09
1

The only idea that comes to my mind is to have a service check the state of the UI application periodically and restart it if it has been killed. There seems to be no standard module that would run within user's session and let the service send notifications to this module. There exist third-party solutions but they can be killed (not saying that they should be installed in order to be used).

Update: after re-reading the question I think that maybe your UI doesn't receive windows messages, so you need another mechanism. Why not create a Semaphore synchronization object in service and wait for it in UI process (in a separate thread)?

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • Let me clarify - I have the UI component already, it's a separate WinForms project which compiles and runs fine. Starting it again isn't an issue as the service will still log device arrivals. Telling the UI (if it is running) to react to an insertion is the issue. – dotalchemy Feb 08 '11 at 22:35
  • @dotalchemy now I am confused. You wrote "This had the downside of the UI element being process killed and no longer detecting device insertions." And your comment negates the quoted statement. – Eugene Mayevski 'Callback Feb 08 '11 at 22:36
  • That was the downside of version one, which is why I rewrote it so the service handles the device arrival and the UI is required purely to display a popup message. – dotalchemy Feb 08 '11 at 22:38