Options for Async Silverlight-to-WPF communication?

Question

What's the fastest communication model for a Silverlight component communicating with a WPF component? That is, at the very least I'd like to consume an event from a Silverlight component in a WPF component.

• I understand you can use WCF to build a bridge
• I understand you can use Javascript to bridge from WPF -> Silverlight (and I have that working)
• I understand you can use COM to go the other way (Silveright -> WPF)

However I'm looking for a tighter communication model (not using COM) - perhaps like EventAggregator (Silverlight component pubs, WPF component subs)...but I've only seen eventAggregation in WPF or Silverlight but not both at the same time.

Any ideas for creating such an eventAgg / eventBus, without using WCF, without using COM?

Open to any approaches / ideas; might be something I haven't considered.

Thanks.

Answer 1

Interesting challenge - could you provide a little more detail on why you need to do this?

My first question is: Are you envisioning these two apps running on the same machine, at the same time? Both are important.

If the answer is yes (same machine, both running) then you should be able to implement a solution using WCF, with the service self-hosted in the WPF app, the Silverlight client referencing it, and a cross-domain policy setup appropriately.

If the answer is yes, but not at the same time, then you'll need a third party, like a Message Bus, perhaps implemented as a Windows Service. NServiceBus comes to mind.

In any case, WCF really is the best solution for messaging in Silverlight. If you were going Silverlight app-to Silverlight app there is a mechanism for that that doesn't require WCF.

A message bus would give you the Event Aggregator functionality you're thinking of - a player who is always there to accept subscriptions and publications.

Another option (if running at the same time) is to elevate your Silverlight app to full-trust and use Sockets. See this link for more info (he provides an example that may be helpful).

Answer 2

Thanks for the input. Yes, LocalMessaging would've been an option, had it been SL-to-SL.

In fact the desired solution is as follows (basically what everyone who's traveled down this path sought, before being consumed by the dragon I assume...wish me luck even for posting it...)

INTEROP! (gasp)

really sad that Microsoft still avoids this concept (imho), when so many have asked for this capability (WPF-to-Silverlight & back). yes, arguments abound as to why you'd want such a thing, etc. but consider LOB apps will be around for some time & so will WPF.

so - looking for the following:

• WPF app/components hosted on local machine

SL components hosted:

• in WPF app using webBrowser control or
• out of browser on same local machine
• SL & WPF components communicating thru events.

...so eventAgg to the rescue, right? well, not specifically. it would have to be SL-to-WPF eventing. and yes, WCF would be an easy option (was actually first idea I threw out, to the folks interested)...but has been scrapped in favor of sockets or other communication which would be faster and not requiring HTTP binding or TCP binding, as WCF would dictate.

it's funny that you mention Mike Taulty since that's exactly where I landed as well (when I mentioned sockets above).

so if I can get that code on Mike's blog working WITH event aggregation...then as Mike might say "bob's your uncle". (i.e. i'm done)

i'll keep you posted with the solution i wind up with - thanks again.