My friend Vittorio has posted that MySpace will be talking about WCF at Mix 2008 ( see it here ). This promises to be a good session!

I thought it might be mildly interesting to document the lifecycle of a demo. Over the next week or so I have to design, build, and deploy a demo that shows off some of the web-centric features of WCF in the .NET Framework 3.5. First, let me state the constraints: 1) it has to be lightweight - a person in the field or in the community must be able to run it with a bare bones setup (VS only) 2) it has to be "codable" from the ground up in a short period of time w/o much practice 3) it has to show

Following on the heels of Steve Maine's post about namespaces in Syndication objects (Feeds, items, etc.), I thought it wise to plug the new stuff in PictureServices . At the moment, PictureServices implements SLE (Simple List Extensions), and does a pretty crude job of it at that. Time permitting, I will add more support for field and group customization. For now, it serves as an example more than a carrier grade implementation. In any event, I used extension methods in the following type definition

I've received several mails about PictureServices and RTM. As some of you know, the Syndication API changed before RTM. The were subtle, but they did have an impact on the Picture Services project. Specifically, the simple list extensions part of Picture Services isn't up to date with the RTM bits. I will update the bits this week and repost...

Today I updated PictureServices to work with the RTM release of Visual Studio 2008 and the .NET Framework 3.5 (what a mouthful). My testing rigor for this release was less than perfect. Please let me know if you find any bugs. For what it's worth, the changes in the API made the simple list extensions implementation simpler. Honestly, I was skeptical at first, but it really is pretty straightforward. Check out the new version here .

It seems that the RSS/Atom article I wrote for MSDN magazine was just published: http://msdn.microsoft.com/msdnmag/issues/08/01/WCFinOrcas/default.aspx The RTM version of .NET 3.5 was not available when I wrote the article, so I avoided the extensibility capabilites of the API. Perhaps that's fodder for another article.

WCF in the .NET Framework 3.5 includes simplified support for building services that adhere to the protocols of the web. To highlight these capabilities, we published Picture Services. Picture Services ( http://www.cloudsamples.net/pictureservices/ ) is a relatively simple sample that exposes pictures using the REST API in WCF. It represents a set of pictures as an ATOM or RSS feed, and provides access to single pictures using simple HTTP GETs. Pictures can come from a variety of sources including

One of the cool parts of WCF in the .NET 3.5 is the simplified support of the REST architectural style. URIs, HTTP verbs, and HTTP headers are 1st class citizens in the programming model. Each of these citizens is interesting. I'll focus a bit on HTTP headers here. HTTP headers dictate a wide array of characteristics of how a server responds to a request and how a client reacts to the response sent by the server. A full discussion is beyond the scope of my blog post, but this stuff has been around

A few days ago we released a new sample called Picture Services. As the name implies, this sample centers on pictures. More specifically, it demonstrates how to use the WCF API in the .NET Framework 3.5 to syndicate images from your local machine and expose them via a REST endpoint. There's been a fair amount of buzz recently around REST development. With the .NET Framework 3.5, REST constructs are now 1st class citizens in the WCF programming model. We've tried to make the sample easy to understand,

I spent this weekend tinkering around with the JSON messaging capabilities of WCF new in the .NET Framework 3.5 (Orcas). The object model is changing substantially between Beta1 and Beta2, and I think the changes make for an easier to use system. To better understand the JSON messaging features of WCF, check out some of the general requirements they were built to: 1) Config-free deployment for JSON endpoints 2) ASP.NET AJAX developer experience consistent with ASMX endpoints 3) Give service developers