We do a lot of WPF/Silverlight development here at ManageScope and we’ve been working with the Facebook C# SDK in *****, our new product that’s inflight. And yes — no comment.

We recently ran into an issue with WPF’s WebBrowser not handling #’s introduced by Facebook in URIs during the authentication process. There’s been some good discussion on workarounds … host Winforms (which for WPF proponents like me is disappointing) … distribute your FB app secret and use “code” instead of “token” on responsetype and then exchange the code for a token. Smart thinking, but I wasn’t really satisfied with either solution.

So for community commentary and/or usage, I thought we’d share what we did to resolve this issue. We decided to use AwesomiumSharp and Awesomium’s WebControl in-place of the WebBrowser control from Microsoft.

A little background … when you’re using WebBrowser in WPF, you’re using Internet Explorer. There are many great products from Microsoft, but I’ve never included Internet Explorer among them. Not only do I have to use a browser I’m not fond of, but I’m stuck using whatever version of IE the user has installed on their deck. Not a great experience if you have users like we do who thought a recent upgrade from IE6 was awesome (just poking fun, guys!).

Awesomium on the other hand uses the Chromium project as its basis. And for those of you who are Chrome users, you know the elegance and speed that Chromium provides since you’re using the same foundation. And these kind and extremely talented gentlemen at Awesomium have also worked to provide a .NET wrapper around this Chromium base as well as a pre-rolled WebControl that replaces the functionality of WebBrowser. There are a ton of great things to say about this product … but they say it better here.

Long story short, the issue went away immediately and we were getting our access token without distributing our app secret or hosting the Winform’s browser. Not to mention we got a better control for creating integrated client and Internet experiences and we’re using something other than IE under the hood. If you’re developing in WPF, check it out.