Monday, February 27, 2012

ClientAccessPolicy or Bust

I won't lie -- I'm no expert, heck, even a decent Web Service developer.  I'm a novice.  If you want an awesome user experience, I'll rock your world, but I digress...

I know WCF is supposed to be pretty easy and cool to work with, so I took it upon myself to write some of our latest "service" code for a demo.  The awesome thing about WCF is that it handles all of the underlying connections and the like for you -- all you have to worry about is the actual logic.  If you want to get a little more "dirty" you can configure which channels it runs over.

So, I wrote a handy little wrapper around our service that handles callbacks, initialization of the connection, and the like.  Whenever it called it, I kept getting a "Security error."  Of course, had I not run through the entire Silverlight debug prompt where it notified me that the service and application needed to run in the same web project, I might have figured it out sooner.

Instead, I decided to make it harder on myself (and actually easier).  I added a ClientAccessPolicy.xml to the WCF service project, similar to how one is necessary for our framework.  The WCF service and application no longer need to be hosted in the same web project -- the ClientAccessPolicy allows the Silverlight client to connect without any issues.

Now, mind you, this is probably a possible point of attack for a hacker if you're not careful, so it's probably best not to do this on a production machine -- but for local development work, it sure helps!