| Comments

If you are starting to get into integrating web services with Silverlight, you'll notice that you have to have a cross domain policy file in place on the target server, that is to say, the server hosting the service you want to implement.  There are some public web services (Flickr, YouTube, Digg, etc.) that already have these files in place for Flash, but implement in a slightly different way.

When calling a cross-domain service, Silverlight will check for the existence of clientaccesspolicy.xml first.  This is the format defined by Silverlight and provides a pretty flexible way to define who can access what services.  If not found, it will then default to look for crossdomain.xml, which is the file format implemented for Adobe Flash.  It is important to note that this file will also still work for most public web services.

But now perhaps you are the author of the service that your application is going to consume and/or the public will consume.  There are a few things you want to consider.  First, it would be a best practice to put your service layer on a separate domain other than your site (i.e., api.mysite.com).  In fact, this is how most are doing it these days.  These helps separate more distinctly the services from the web site and also separates the cross-domain security concerns away from the content site versus API access.  Once you have done that you'll want to implement your specific clientaccesspolicy.xml file.

When Silverlight 2 was released to beta, I created some quick helper files to assist me with creating this simple policy file (it is simple, but can get complex depending on how granular you want to define your access).  I figured it might be helpful to some who are implementing services as well.  Sure, they aren't going to save the world, but might save you some quick typing.

Visual Studio Code Snippet

The slcap.vsi file is a Visual Studio Community Installer package which contains "slcap.snippet," which is a Visual Studio code snippet format.  This is an XML snippet, so would be used only in the context of an XML file.  Just double-click on the .vsi file to install and it will walk you through the steps.  I recommend just keeping the defaults.  After it is complete, you now have an Intellisense snippet.  To use it and create a new clientaccesspolicy.xml add a new XML file to your web service site/project named clientaccesspolicy.xml.  It will open a blank XML file by default.  Select all text (CTRL+A).  Then hit the keyboard shortcut for launching XML snippets, CTRL+K,X.

NOTE: For some reason XML snippets don't operate like C#/VB ones do where you type the shortcut, then TAB, TAB.  If anyone knows why, let me know :-)

This will bring up the navigator, then simply navigate to the My XML Snippets, then locate the one you just installed:

Once you select it, there are three literal areas to override the defaults if you wanted. 

UPDATE: As Sean probably ran into below (in comments), the above screenshot does not show the required http-request-headers attribute required on the allow-from node of the policy file.  This is, however, updated in the Intellisense files and the code snippet template.  Thanks Sean for pointing out the screenshot is wrong here.

If you are implementing a completely public web service (open to anyone for cross-domain access), then the defaults will suffice.  When done changing the values, hit enter and you are done.  For those who are not keyboard shortcut masters and would be using a mouse to do all this, it might not be terribly faster to be honest (if the TAB,TAB implementation was there for XML snippets, it would eliminate the arrow up/down to navigate to the snippet).

Get the slcap.snippet here.

Visual Studio Intellisense Files

This next step is a super hack that I originally did and decided it might not be a good idea, but I'll include it here anyway :-).  This involves adding Intellisense files to your VS2008 installation and if you aren't comfortable with that, then move along.

First, you'll want to get the XSD I created, which is very simple and I'm sure doesn't fully conform to the final spec, but lacking that spec, it maps to the format well enough.  Copy the clientaccess.xsd file to the C:\Program Files\Microsoft Visual Studio 9.0\Xml\Schemas location (or wherever VS2008 is installed for you).  Once you've done that you have to add an entry into the catalog.xml file to add the mapping.  Again, not this is my little hack so I created some namespace because there wasn't one defined yet.

Once you have those two files you have Intellisense for your clientaccesspolicy.xml file if you want it.  Following similar steps as above, create the new file.  This time, however, type the root node of <access-policy> but adding the 'xmlns' attribute pointing to the new namespace you just added to the catalog file (note: Intellisense should give you a list to choose from:

Once you have that, then you'll get the rest of the Intellisense for the basic format of the client access policy format.  If you have multiple allow-from/grant-to needs, this Intellisense will support it.

The only lame thing is you have my namespace in there :-).  That is what drives the Intellisense.  Right now you'll want to remove that before deploying the actual file.  Yeah, I know.  But I said this was an early hack of mine didn't I?

Get the Intellisense files here.

What do to with the completed policy file?

Either way, when you are done with the file, it needs to go in the ROOT of the domain.  This is important as it is not the application root, but the root web.  Even if your app is at foo.com/myapp, the policy file needs to be at foo.com/clientaccesspolicy.xml.

Anyhow, maybe these files will help you.  Ideally you won't be using/messing with an access policy file much, but this might save you some clicks and having the docs open next to you :-).

| Comments

The Code Trip LogoWow, it's been a few months now since I thought about doing a road trip talking about the next wave of technologies.  I originally thought it would be the "Silvertour" but we've now actually made it happen.  I can tell you that the behind the scenes of this has been a long process.  It seems so simple and I can hear the people now saying 'why was it so hard, c'mon you are Microsoft and have zillions of dollars.'  Sure, maybe that is true about a big company, but that's also the point.  We are a company of companies and thus we still have budgets.  For me, that's been the biggest challenge wrangling in budgets, efforts, desires, balancing other goals, etc.  It's been a long process.

But it's on baby.  The Code Trip is coming...like in a few days literally.  We thought small (budgets) and wanted to go the RV route.  Well, for various reasons (stop by an event and we can chat), we got a friggin tour bus.  And in fact it's the tour bus coming off the Styx tour.  How crazy is that?  Here's a preview of what we'll be cruising around the western U.S. in:

The Code Trip Bus

So we're off...leaving from MIX on Thursday, March 6 (stop by the blogzone to help send us off).  Our schedule is up on the site and will be continuously updated.  The site will be evolving after MIX announcements :-).  We're excited to head out.  We know we've forgotten things probably.  Heck, it will be a great time and we look forward to seeing you all on the road.  Visit the site, subscribe to the main feed, follow us for real-time updates on Twitter and become a fan on Facebook.  We'll be having contest announcements TODAY as well so you'll want to make sure you follow all those links as we'll announce some contest in certain areas.

From MIX we'll be hitting these cities first:

Please join us in person if you can, but follow us on line to view our daily log podcasts and code samples we'll be putting up.  See you on the road!

| Comments

When developing Virtual Earth applications I find myself always having the SDK documents open in the background for reference.  While this isn't a bad practice, I've historically only used them for parameter reference, etc.  I longed for the time that I could get cheater help intellisense for the Virtual Earth API. 

When Visual Studio 2008 came out with Javascript intellisense, I figured the day has come.  But unfortunately, the Javascript intellisense isn't enabled for external (external==not-the-same-app-domain) files.  The thing about the implementation of the Javascript intellisense in VS2008 is that you can just make a reference to a file for the intellisense and it doesn't have to actually be the implemented file.  Make sense?  Probably not. 

My colleague Marc has created a Codeplex project for enabling Virtual Earth intellisense.  Basically he's created a helper Javascript file that you can reference in your project to enable the intellisense.  Note that this does not actually get referenced in your project (meaning, the Javascript file isn't downloaded to your users), but rather just leveraging the VS2008 Javascript intellisense reference scheme to 'trick' the IDE into giving you intellisense for your referenced Virtual Earth API.  This is accomplished because the Javascript reference of the helper file is a design-time only helper...not affecting any true reference to the Virtual Earth control.

Once you do that, you'll get something like this:

Marc did a great job getting a lot up and running with this helper file.  He's recorded a short screencast on how it works to help you understand it a little better.  And if you are interested in helping contribute to the project, please watch the screencast for more information.

| Comments

Very cool think popped in my RSS reader this morning.  Scott Guthrie (now a corp VP, congrats Scott) put up a first look post at Silverlight 2.  Not just a 'here's what is coming' but an 8-part tutorial as well as he built a sample application trying to leverage and demonstrate various parts of Silverlight 2.

These tutorials should be extremely helpful for those wanting to understand some of the newer concepts brought to Silverlight.  If you haven't done a lot (or any) WPF coding before, some of this should jumpstart your knowledge a bit.

take a look at 'First Look at Silverlight 2.'

| Comments

finally want to try out that feature to debug your apps and step into System.Web.dll?  it has arrived.

shawn burke has all the blow-by-blow details on setting it up.