IRhetoric - Karsten Januszewski : Vista

The Definitive Post on XBAP Trust Levels

karstenj — Fri, 12 Jan 2007 00:53:00 GMT

I've written about XBAPs and full trust in the past, but never as thoroughly as Karen Corby just did in her post on XBAP trust levels. She spent a lot of time getting this post correct, reviewing with various folks within Microsoft and providing very solid guidance. It is the kind of post that should be in the SDK and official docs, but didn't make it due to time constraints. If you have questions about XBAPs and full trust, this is a must read. Her deployment recommendations in particular are essential if you are thinking about going down the full trust XBAP road. But keep her guidance in mind: only do this if you must. ClickOnce .exe's are pretty slick and don't have nearly the issues associated with them as full trust .xbaps.

Yahoo Messenger for Vista Debuts at CES

karstenj — Tue, 09 Jan 2007 20:32:00 GMT

I'm here at CES, where Yahoo and Microsoft showed off a preview of the new Yahoo Messenger for Vista, built entirely on WPF. Yahoo has a great landing page with screenshots, a screencast of the app and a sign up sheet for when they release a beta. I held off on blogging this until we got the Channel 10 interview posted, where I hooked up with Jeff Sandquist and the crew to do an interview with the Yahoo folks, Joshua Jacobson and Matthew Skyrm, about the application. (If you haven't seen Channel 10, it is the sister to Channel 9, targeted to enthusiasts and power users.) They talk about their motivations for building this new messenger, their experience with WPF and Expression and more. They've got a blog up as well! I've been working with the lead developer, Eric Burke, along with Frog Design, including Lee Brimelow, on this application and the alpha is looking great. This application is a shining example of the opportunities and possibilities of the Vista and .NET 3.0 platform. Expect to hear more about this, for sure...

Inter Process Communication Between Applications and Vista Gadgets Using WCF (Part 2)

karstenj — Sat, 21 Oct 2006 01:17:00 GMT

Once I got WCF working in a gadget, another scenario came up: wouldn't it be nice if the gadget and the application shared a data model? The gadget could remotely databind to the same data that the application was databound to. As such, there would be one data source, owned by the application, that the gadget could both manipulate as well as receive updates when things changed. To be clear, there are not two data sources that I am trying to keep in sync, but rather one data source owned by the application which the gadget reads and writes to. (It does have a "local copy" but from the code never touches the "local copy" and only manipulates the data source through its proxy class to the master copy.) I wanted to use as much of the WPF databinding as I could to try and get some of the databinding goodness for free. I based the code on a sample in the SDK under the WCF samples called Data Binding in a Windows Presentation Client. Also, I found this blog post helpful.

Download the code and gadgets.

The architecture is different than my earlier example because there is a more pure client/server relationship between the application and the gadget. The application acts purely as the server and really could care less if it has any clients. The gadget acts as a client only, unlike my earlier sample.

Similar to my earlier sample, I removed the metadata exchange and share type between projects. Again, because no one else will be using the service, it turns out to be simpler to just share the code and not rely on the proxy code generation tool. In this case, I have have data contracts shared as well as contract. The contract itself is a bit trickier because I am using a Duplex channel, which is what allows the application to notify the gadget that data has changed. As such, I decorate the contract with the SessionMode=SessionMode.Required attribute. I then decorate the server implementation of the contract with [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,ConcurrencyMode = ConcurrencyMode.Multiple)]. Notice that I still have an InstanceContextMode of single, so that I only have one instance of the service object, but I allow a ConcurrencyMode of multiple, so that if there were multiple clients to the service, all would still be hunky dory. (Thanks to Craig McMurtry for helping understand the right choices to make here.)

In the implementation of the service, I used a trick I picked up from the fantastic samples up at the IDesign site. Basically, I use their technique of registering a list of clients through the use of a Connect method. Once a client is registered, it can be called back from the server. The convention of Disconnect allows the server to clean up any subscribers. Nice!

As I mentioned earlier, I wanted to try to preserve as much databinding goodness as I could. As such, I subclasses ObservableCollection and overrode the OnCollectionChanged event. It is within this event that I callback to any listeners to let them know that the data has changed. Unfortunately, I couldn't simply serialize the NotifyCollectionChangedEventArgs. As such, it would take quite a bit of custom code to truly serialize this event -- looking at Reflector is a good start if you are interested in doing this. For my purposes, I just notify the client that the data has changed so that they can rebind. It is worth calling out that this same technique could be used to serialize the INotifyPropertyChanged event as well, for more granular control over changes instead of the brute force approach I took here.

One thing I do in the client (which I also learned from the IDesign site) was to create my own asynchronous proxy class, rather than having the svcutil tool generate it for me. I then use a slightly different technique in instantiating the client than I did in part 1. This time, I create a DuplexChannelFactory which I use to new up clients to the service. Another thing I did was not use config files but rather I have things like the endpoint hardcoded into the app -- more secure.

I do something simliar as I did in part 1 as far as making the gadget reliable in the event that the application isn't running by wrapping the initial Connect operation in a do/while statement, nulling out a client object if it fails to connect.

The asynchronous databinding is entirely lifted from the SDK sample other than the moment where I get a callback. At first I tried to call the service as soon as I received the CollectionChanged notification. However, this created a race condition. So, I call the service on a background thread when I receive the callback, which worked out fine.

The WPF code itself is wrapped up in an ActiveX control, as discussed in this post. Nothing new here. Of course, installing the ActiveX control requires elevation.

So, to get the sample working, first run the install.cmd from a cmd prompt run as administrator to register the ActiveX control. Then, compile the databinding_serv.sln file in the sources directory. Again, if you don't have VS on your Vista box, you can use this trick from Tim Sneath to compile from a command line. You'll notice that the gadget binds to the application's data whenever the application comes online. If you update the data in the application, the gadget will get updated. And if you update the data in the gadget, the application's data is updated. Note that I never manipulate the data directly within the gadget, but always through the proxy. Also, note that I rebind to the gadget data every time, which isn't super efficient and could be a problem with larger data sets. Of course, it is communication on the same box, which is pretty darned fast. Go WCF!

Download the code and gadgets.

Inter Process Communication Between Applications and Vista Gadgets Using WCF (Part 1)

karstenj — Sat, 21 Oct 2006 00:46:00 GMT

I recently faced the design challenge of getting an application and gadget to communicate. How to solve the problem? Well, what better way to talk between applications than Windows Communication Foundation (WCF). After all, it is the inheritor of the .NET Remoting legacy, which is what would be used in the past. It was quite enjoyable to return to writing WCF code, which I hadn't done for awhile. It really is the analog to WPF in terms of beautifully factored code architecture. In part 1, I'll show my first prototype, which used an XBAP gadget acting as both a server and a client that sends mouse movements over WCF to trackball either the application or the gadget. In part 2, I'll show my second prototype, which shows an ActiveX-based gadget acting as a client to the application and databinding to the application's data model. I subclass ObservableCollection and show the beginnings of what I dubbed SerializedObservableCollection. Download the code and gadgets.

Before explaining how I went about coding this, please be aware of all the issues with WPF gadgets raised in this post.

Part 1

The first project remotes mouse move behaviors such that you can trackball the gadget and change the application. Or, you can trackball the application and update the gadget. In this case, the gadget is an XBAP. Now, because XBAPs run in partial trust, I had to change the XBAP security settings to allow for WCF, which requires full trust. This was just a matter of tweaking the settings in the security tab of the project properties. Because the XBAP is being launched from the file system, this does not present any deployment problems. Were the XBAP to be deployed from a serer, the certificate used to sign the XBAP needs to be installed in the trusted publishers list on the user's machine. In an installation routine, one could call certmgr /i under the covers. The other option here would be to place the WCF code in a seperate assembly marked as Allow Partially Trusted Callers (APTCA) and register it in the GAC. To protect the APTCA assembly, it should be locked down using FriendsAssembly concept (InternalsVisibleTo). That way only the Xbap that put the APTCA assembly can call into it. In this case, XBAP itself can stay in sandbox but APTCA assembly acts as a proxy between XBAP and full trust calls. I haven't done this myself but I've been told it works.

The way the WCF architecture works in this sample is that the gadget and application each act as both a server and a client. So, when you are trackballing the gadget, it is acting as a client to the application and sends messages about mouse position to the application, which is listening. As soon as the application is trackballed, the roles flip and the application then acts as the client and sends its mouse events to the gadget, which listens as a server.

All the communication uses the netNamedPipe binding of WCF. This is established in the app.config file. One interesting fact is that the messages between the app and gadget are signed and encrypted, which is cool. No other rogue application could sniff the traffic between the gadget and application. I have turned off the metadata exchange features of WCF. This means that to create my client proxy for talking to the service, I had to either use svcutil.exe on the application itself or, rather than generate a client, I could just craft up my own proxy, which I did. After all, no one else is going to consume the service but my own code. In fact, all the code is in a dll called RemoteMouse, which is shared by the XBAP gadget project and the application.

One area that was a little tricky was protecting both the gadget and the application for the possbility that one would not be alive. I achieved this by instantiating the client proxy on a seperate thread. If I get an exception from the server -- which would most likely occur if the gadget wasn't launched or the application wasn't launched -- I brute force null out the client and create a new one in a do/while loop every second. This might sound expensive, but turns out not to be. I found this approach easier than handling lots of events within WCF around the CommunicationState enumeration. One thing I don't do is nicely disconnect from the server, which I should do.

The way I host WCF within WPF is based on a sample in the SDK in the Cross Technology Samples/Integration Samples for the .NET Framework 3.0 Features called Hosting A WCF Service in WPF. It turns out to be pretty simple and elegant. I have an interface called IDisplay, which is implemented by the Trackball control. Then, when I create the WCF service, I pass a reference to the trackball class to the service in the constructor to the service. I can then call methods on the trackball from the WCF service. Pretty nifty!

To install, double click the RemoteMouse.gadget file. Then, compile the cubeapp_exe solution. If you don't have VS installed on Vista, no problem. Just use the trick Tim Sneath outlines here, as every build of Vista has all the tools needed to compile .NET 3.0 apps.

Download the code and gadgets.