I’ve posted part two in the (now) three part series of articles about jQuery with ASP.NET today. You can read the article here:

jQuery with ASP.NET (Part 2: Making Ajax Callbacks to the Server)

Part 2 of this article series deals entirely with various ways of interaction between jQuery and ASP.NET server side code for making AJAX callbacks.  If you have any questions or comments regarding this article please leave them below.

If you missed Part 1 – it is an introduction to jQuery and focuses primarily on the client side features of jQuery.

An Introduction to jQuery (Part1: The Client Side)

Although this article uses ASP.NET for the sample discussed the content in Part 1 is really server platform agnostic.

Part 2: Focus on Ajax and Server Callbacks

The new article first introduces the basic features available in jQuery and then proceeds to demonstrate a number of different ways to call ASP.NET code. A wide variety of topics are covered from basic .load() calls to separate URLs, to same Page callbacks with Html and JSON data. The bulk of the article focuses on interacting with WCF and ASMX services for raw AJAX callbacks that treat ASP.NET primarily as a data backend for a client application. There’s also some discussion of using client side templating for rendering and maintaining HTML in one place and several extensive sample applications are provided to demonstrate the concepts.

The sample project also includes a host of utilities and what is basically the West Wind Ajax Toolkit Version 2.0. The jQueryControls project contains a number of server controls that simplify a number of client scenarios and also includes a few useful utilities like the ClientScriptProxy, ScriptVariables and ScriptContainer components. The tools have all been updated to work with jQuery on the client.

The article is fairly long (yeah, yeah what else is new?) , mainly due to a fair number of code listings and detailed discussion of some of the examples. As I was writing this thing I was trying to incorporate a number of the questions and comments I’ve heard in the last few months. Hopefully some of you will find this useful.

I thought I was going to do only two parts in this series, but since I ran a bit long on the AJAX portions I decided to leave the server side integration topic (server control creation, wrapping client functionality etc.) for another article. Not only would this article have gotten too long but it would also have blurred the focus at the end. Eeek, two down one more to go…

I’m a big fan for using AJAX callback services in my AJAX enabled applications. I prefer the low level approach where the server acts as a service and only feeds data to the client and the client then manages updating the data and updating the UI with that data accordingly. On the .NET platform there are a lot of options available for doing this from using ASMX Web Services JSON support via the ASP.NET AJAX Web Services, to using WCF 3.5’s REST services to a number of free solutions that provide simple and easy to use connectivity from client to server.

A while back I’d talked about using WCF for REST services with jQuery and there was a ton of interest in this particular topic. I also noticed Dave Ward’s topic (which is great complement to mine) also has gotten a lot of traction and there certainly is a lot of interest in using WCF for AJAX callbacks. I get questions  from people almost daily who want to know something related to the WCF functionality or – almost as frequently – asking whether WCF is the right choice for AJAX Web Services.

WCF REST Services – worth the hassle?

Let me start off by saying that I’m a huge fan of WCF as a service framework for building Web Services and any sort of inter application communication interface. However, I’m much less enthusiastic about the WCF REST functionality and the AJAX functionality in particular. That’s not to say that I don’t use them – I think in the end WCF will replace ASMX for Ajax callbacks. But the reality for me is that WCF REST set up and operation is more error prone and requires more resources than the older and simpler ASMX services.

In the end what it comes down to is that using WCF doesn’t really provide any significant improvements over ASMX based AJAX services. There ARE new features in this part of the WCF stack, but most relate to the actual REST functionality rather than the AJAX features which realistically shouldn’t be lobbed into the same technology space. If you are using ASMX now and you’re moving to WCF for those same AJAX services don’t expect any new features other than ‘it just works’.

There are really two new features in the WCF 3.5: REST functionality which is based on the REST architectural guidelines of using URL based routing, plus usage of Http Verbs to specify intent on service operations. And then there is the RPC style interface functionality that we typically use for AJAX based applications to make AJAX style callbacks to the server from client applications. In WCF 3.5 both of these technologies sit under the same umbrella because they basically use the same functionality – non-SOAP based HTTP endpoints – although from an application architectural POV they are used quite differently.

REST is meant to be URL and Http Verb based, but typical AJAX callbacks – especially those that are based on ASP.NET AJAX - really only use a single endpoint URL and POST data to the the server. ASP.NET AJAX applications aren’t really REST in that they don’t follow typical REST recommendations (not that this semantic difference matters much in a pragmatic sense).

WCF REST is WCF – sort of

I was excited to see a dedicated HTTP REST and AJAX interface to WCF introduced in .NET 3.5. Prior to .NET 3.5 WCF provided only SOAP based services and SOAP based services are notoriously difficult to consume for ‘light’ client interfaces that don’t have native SOAP clients. Consuming a SOAP endpoint in HTTP for example would be rather painful. Instead many client applications today use either plain xml (POX) end points or more likely for Javascript client applications JSON endpoints.

WCF REST provides the pure HTTP based endpoint infrastructure that allows returning non-SOAP content in XML, JSON, RSS and Atom formats, plus the ability to return pure data via .NET streams which allow returning any sort of binary data like images or HTML or anything else so any type of content can be served from a REST endpoint. What this means in a nutshell is that you can use the standard WCF messaging model to return non-SOAP based HTTP data to clients.

I’ve already been using WCF and having this functionality extended to JSON services initially sounded like a great idea. But it quickly became clear that pure WCF REST services are very different than other services: An existing WCF service doesn’t work out of the box as is as a REST service. Unlike other service types that can switch between protocols with just a few configuration switch settings  REST requires that the service contract is marked up with REST specific service attributes on each operation like so:

[OperationContract]
[WebInvoke(
    Method="GET",                       
    ResponseFormat= WebMessageFormat.Json,
    BodyStyle = WebMessageBodyStyle.Bare,
    UriTemplate= "GetStockQuote/{symbol}")
]
StockQuote GetStockQuote(string symbol);

Each endpoint method specifies exactly the format that is used to return data to the client. There are quite a few custom attributes and they are mutually exclusive – any of the options unqiuely configure each endpoint so it’s not possible to create an endpoint that returns either Xml or Json, or a  bare or wrapped response based say based on the type of input that was received. Based on the design of WCF’s functionality that actually makes as one endpoint maps exactly to one messaging format. But it makes for a bit of a hack if you plan to expose and/or accept data in different formats. Essentially you have to create multiple methods with different names to expose data in different formats and – optionally – provide a custom UriTemplate template to make it seem seamless. For example if I want to return data both in JSON and XML I might have to do something like this:

[OperationContract]
[WebInvoke(
    Method = "GET",
    ResponseFormat = WebMessageFormat.Xml,
    BodyStyle = WebMessageBodyStyle.Wrapped,
    UriTemplate="Quotes/{symbol}")  
    ]          
StockQuote GetStockQuote(string symbol);


[OperationContract]
[WebInvoke(
    Method = "GET",
    ResponseFormat = WebMessageFormat.Json,
    BodyStyle = WebMessageBodyStyle.Bare,
    UriTemplate = "Quotes/{symbol}/json")
]        
StockQuote GetStockQuoteJson(string Symbol);

with two method implementations required that basically do exactly the same thing.  The only difference is the UriTemplate and the ResponseFormat. Again this makes sense for the way WCF works, but from a logistic implementation POV this means if you want to support 4 different message formats you end up exposing 4 different endpoints/methods (even if each just calls a base function to do the actual processing).

What’s even worse though is that you can map an endpoint only to a single HTTP verb and document input/output type. You can’t have a single endpoint to serve both GET and POST or based on parameters serve either Xml or JSON. While this might be OK for a pure REST implementation, for a typical AJAX service this is not optimal. When building an AJAX API it’s not uncommon to want to have clients access through both query string parameters or POST variables. AFAIK this can’t be done with a single WCF end point because again you’re specifying a whole bunch of service specific behavior on each method in the service contract.

If you add 4 output types plus maybe two different operation types for that endpoint  you end up with a plethora of methods to service that one endpoint. It gets messy REALLY quick and really makes you wonder: Wouldn’t it just have been easier to create an HttpHandler that has a single end point mapper and properly deserializes/serializes data based on a set of standardized input parameters? After all there is a DataContractJsonSerializer plus the XMLSerializer that can be used to serialize and de-serialize objects fairly easily. I’ve wondered this on several occasions even as I was putting together some of my relatively simple examples for my session. I imagine it only gets worse once you start building more complex services that expose a full complement of REST operations for REST manipulatable data or content.

Even if you stick with a single message format you are still required to specify the format on each Operation/Method. It sure would have been nice if WCF REST supported some mechanism to specify default formats for all those message format attributes that can be defined once at the Contract/Class level. But no – that’d be too easy.

All this service behavior markup too gets tedious as it has to be added to each endpoint method which means lots of repetition. If you decide later on you want to switch to a different message format you have to hunt through all service methods and change all of the attributes on them.  Unlike other services were behavior is set once on the service and only occasionally overridden the pure REST interface requires individual attributes.

No Authentication

WCF REST also doesn’t support any authentication schemes unless you enable enable ASP.NET Compatibility. You can use Windows Authentication with REST Urls but you can’t even easily retrieve the log in info unless you’re using ASP.NET compatibility. So your choices for authentication are use ASP.NET compatibility (described below)  and take advantage of Forms/Windows/Membership Authentication or roll your own. One of the big draws of WCF is that so much infrastructure is provided for you so you don’t have to reinvent the wheel for every protocol nuance. But WCF REST lacks most of that beyond the basic protocol implementations.

Single ASP.NET Authentication Mode Support
WCF REST only supports a single authentication mode in an IIS Web site. This means you can have EITHER anonymous or Windows Authentication going in the site, but not both. When you do both you get a nice yellow screen of death:

This is actually a potentially big deal if you plan on dropping WCF REST into an application that has to support both public and authenticated access. I haven’t seen a way to get around this issue and this will make WCF REST a non-starter in a number of situations – I know it has for me. You can’t always choose what format is used as the rest of the application might determine the security environment.

This seems like an arbitrary limitation, since obviously IIS supports mixing schemes. I can understand multiple actual auth schemes not being supported, but at the very least anonymous should always work. Alas it doesn’t and it’s a bummer.

Error Handling

In non ASP.NET Compatibility mode, you’ll also find that the error handling is horrible. Instead of an response that is returned as JSON to the client you get an HTML error page that is completely useless to the client that can do nothing other than try to parse out the error message. This makes sense for pure REST scenarios, but in a JSON callback scenario an HTML message does not provide anything useful to the client – what’s really needed is like standard WCF an error returned in the appropriate message format (ie. JSON). There’s no built-in way to return an error in a JSON scenario as an error object – instead HTML is returned. You can roll  your own to do this (or again use the ASP.NET AJAX specific script factory) but that’s not a trivial task.

The REST Starter Kit improves this slightly. It provides some new WCF REST extensions that provide the abililty to throw errors from server code more easily and output error output pages that are much leaner than the typical Yellow Screen of Death you’d get by default. BTW, the starter kit provides a host of useful new features although one really has to wonder why this stuff wasn’t added to the core product in the first place.

Some of these limitations make sense for the platform – it’s the way WCF works, but maybe that’s precisely why the REST features are maybe not such good fit for WCF.

ASP.NET AJAX HostFactory makes things easier than ‘plain’ REST

What I described above mostly relates to pure REST interfaces where you specify every option you want to use explicitly on each method using the WebInvoke or WebGet attribute.This allows you maximum flexibility for your messages but it’s also tedious to do on each and every method. This is probably reasonable for ‘real’ REST based applications that are exposed to be accessed by the whole world , but for a typical AJAX callback service that gets only by your application to provide data for client pages that would be overkill. Typical AJAX applications aren’t concerned with REST semantics, but need to efficiently and consistently retrieve AJAX data.

Luckily Microsoft recognized this needs as well as the existing base of ASMX style AJA X services  that work with the ASP.NET AJAX infrastructure. If all you’re after is compatibility with ASP.NET AJAX and to replace AMSX with WCF  – there’s a shortcut that provides WCF REST the same functionality that ASMX based AJAX services provide. Microsoft was smart enough to release a SerivceFactory that provides in effect ASP.NET AJAX compatibility out of the box. It provides the same ‘wrapped’ JSON message format that ASP.NET AJAX uses, the script proxy (the /jsdebug option), error management by wrapping exceptions into objects that get marshalled back to the client as JSON objects. Some of these features – like the error management is only available to this specific ServiceFactory.

So to set up a pure AJAX service  you can use the WebScriptServiceHostFactory on the service definition in the Service markup:

<%@ ServiceHost Language="C#"       
                Service="WcfAjax.MsAjaxStockService"  
                CodeBehind="MsAjaxStockService.svc.cs"
                Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory"                     
%>

which makes the service ‘config-less’ (the entries in Web.config can be removed), provides the /jsDebug proxy generation and serves and receives data in  Microsoft’s wrapped JSON format and error marshalling as JSON. No settings in web.config  are required and none of the endpoint methods require any attributes beyond the OperationContract to expose the method.

[OperationContract]          
StockQuote GetStockQuote(string symbol);

When using this model the input is always a POST JSON string in the MS parameter format which is in the mode of parameter key value pairs (ie. { “parm1”: value, “parm2”: “value”}. Output is always returned in the MS wrapped format which has a ‘root’ object with a single property that actually holds the result value. The wrapped format includes a root node, plus type information on each marshalled object value returned from the server to facilitate two-way serialization.

{"d":
     {"__type":"StockQuote:#WcfAjax",
      "Company":"Microsoft Corpora",
      "LastPrice":20.49,
      "LastQuoteTime":"\/Date(1227751200000-1000)\/",
      "LastQuoteTimeString":"Nov 26, 4:00PM",
      "NetChange":0.50,
      "OpenPrice":19.83,
      "Symbol":"MSFT"
     }
}

This format is specific to the WebScriptServiceHostFactory as far as I can tell. Although similar to the stadard BodymessageStyle.Wrapped the format is different as the base version does not include type information for objects and names the root node differently. IOW, this is a very ASP.NET AJAX specific implementation.

By default when using the WebScriptServiceHostFactory,  ASP.NET compatibilty – the abilty to access the HttpContext object and its intrinsic ASP.NET objects – is not enabled. If you have existing ASMX services you want to migrate to WCF and those services rely on things like Session or Request you need to add one more setting to your Web.Config:

<system.serviceModel>

  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

</system.serviceModel>    

Then on your service:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class RestStockService : StockServiceBase, IRestStockService

Options are Allowed, Required, NotAllowed. Note that this is specified on the implementation class rather than the service contract interface.

If you don’t need ASP.NET compatibility, it’s best to turn this option off, but if you have an existing ASMX service that uses say the session object to track users, it’s handy to be able to fall back onto ASP.NET objects. Realize when you do use ASP.NET features you are obviously tied to ASP.NET and IIS. REST services CAN be hosted in alternative hosts (self hosting for example) but if you use ASP.NET compatibility only ASP.NET app hosting is allowed.

Using the WebScriptHostFactory is a quick way to migrate existing ASMX services to WCF. However, keep in mind that realistically doing so will buy you nothing in terms of new functionality or features other than being able to say the app runs on WCF. However, going forward I suspect that any further improvements to the ASP.NET AJAX engine will be made to the WCF engine rather than ASMX, so going forward and especially for creating new services it’s probably not a bad idea to start using WCF services. It’s not really any more complicated than ASMX services as long as you use the WebScriptServiceHostFactory.

Stability

One big concern I’ve had with WCF is that I’ve had some stability problems with the .SVC file in my ASP.NET projects. The issues are mostly in the development environment, but it’s been a huge time sink. The problem I’ve run into is that the .svc file on the server somehow gets out of sync with the compiled code and causes a yellow screen of death for a compilation/temporary file error as I described here. These errors pop up randomly on apps that have been working just fine and even though the service file or the service related classes and interfaces have not changed.

Things get a little better if the following configuration setting is used in <system.web>:

        <compilation  debug="true" batch="false">

which makes this compilation error less of a problem. But it still happens to me from time to time and once it does it takes a few IIS restarts to get the application running again.

Do you need to use WCF rather than ASMX?

So where does that leave us? WCF REST provides new functionality but be prepared to spend some time with it, especially if you choose to not use the ASP.NET AJAX specific WebScriptHostFactory. Figuring out how to get WCF to return just the right contract can take a little tweaking.

As to switching from ASMX to WCF for AJAX services – if you have existing services that work with ASMX I really don’t see a compelling reason to switch to WCF. There are no new features so at best you get the same functionality you had before running WCF. If you do decide to go forward to WCF – updating is pretty easy. It basically involves migrating your classes by updating the various attributes [WebMethod] attributes to [OperationContract] attributes, so all in all that’s a pretty painless migration. Remember that if you use ASP.NET intrinsic objects anywhere in your service to enable AspNetCompatibilityEnabled in Web.config and set the attribute on the service class.

Going forward for new services using WCF is probably not a bad choice since it’s really no more complicated than ASMX to set up if you use the script factory.

Still I’m fairly wary of the new WCF features. I wanted to be exited and move forward, but ultimately WCF just doesn’t bring any benefit to the party, but rather makes things more complicated by requiring additional references and  requiring more resource. Most AJAX based ‘service’ interfaces are not real services but are very closely tied to the Web application. They tend to be private services used for internal use of the application, rather than widely accessed public services. For that task WCF REST services might have more appeal.

So I’m finally getting an opportunity to work with Silverlight in a real application. I had mentioned this application in the past a few weeks back – the original application architecture was created as a Flash front end to a .NET backend which provides service style XML data. In the original app the server infrastructure was used purely to serve data to the client – basically a complex, mostly meta data drive SQL Engine based on complex stored procedures feed the client Xml data. Originally our data format has been DataSets because those were the easiest way to consume the data in the Flash client since there’s native support for DataSets and it greatly facilitated the process of passing data to flash and the format is basic enough that it’s easy to send update data back from the client (manually created in this case).

In the original app I basically built the data engine – which is a custom HttpHandler based affair that basically is a glorified XML routing engine that maps inbound requests from the client who sends XML data to the appropriate business object/Stored Procedure routine which in turn responds with a data result that is streamed back to the client. The server app and business objects actually do very little work in this process – most of the work lives in the SQL backend with its stored procedures that manipulate the data. The business object’s tasks mostly is to pick up inbound query parameters and map those into the appropriate stored procedure calls. The results for now are returned were returned as DataSets and there’s a bunch of extra logic that can also return that same data out as either JSON or as simplified XML (without DS schemas).

This has all worked well, but it’s been based on the existing Flash expertise at the time, which have now become an issue.

So based on some back and forth discussions the thinking now is that since we’re starting from scratch Silverlight is probably a better choice due to the easier coding model and readily available developer pool. Which has landed me smack in the middle of Silverlight and not least of all a data access decision to make. :-}

Data Models

The main issue I’m working on at the moment is finding the right data model. The server side as it sits right now has a number of options for returning data to the client. Silverlight has many options for getting data to the client:

Raw Xml

Obviously we can retrieve the raw XML from the server and just parse that on the fly. While not difficult this would not be my choice for data access because it’s tedious and potentially error prone. Since the data is mostly dynamic and doesn’t lend itself to mapping well though this is not totally unreasonable because we’ll likely end up with some sort of untyped data representation on the client no matter what.

JSON or ADO.NET Data Services

As I mentioned our backend can actually feed data out as JSON so another option I was toying with is to use JSON marshalling to map onto objects. The problem with this approach is that we don’t really have a model we can map to. The problem is that the backend (over which I have no control at this point) is just a fairly large set of heavily parameterized stored procedures. While the actual simple tables in the system are fairly small and could be modelled, the way the data is manipulated and returned does not lend itself well to producing either a Linq to SQL or Entity Framework data model. We’d end up with about a hundred or more hand created types that would have to be kept in synch with the database. That doesn’t sound very promising either.

ADO.NET Data Services could be interesting for certain data scenarios, especially free form data access, but my current scenario isn’t one of them I think. Still digging through the docs on ADS but I think when dealing with stored procs there’s really nothing here to help effectively. Nor is the structure of this architecture really a good fit. To make this work would be square peg, round hole.

Web Services

Web Services provide another possible option. Silverlight can directly access WCF Web services and retrieve data that way and this is actually a pretty easy interface to work with. But again it requires fixed, typed result sets so the issues are somewhat similar as the previous  item. You need to be able to full type information published on the server in order to get the data back to the client.

One thing I was thinking about was to return a result back from a Web Service as a generic dictionary which actually serializes properly, preserving underlying type information:

[OperationContract]
public Dictionary<string, object> GetDictionary()
{
    Dictionary<string, object> items = new Dictionary<string, object>();

    items.Add("Field1", 10);
    items.Add("Field2", DateTime.Now);
    items.Add("Field3", "Rick");

    return items;
}

Properly returns in Silverlight as:

private void btnService_Click(object sender, RoutedEventArgs e)
{
    PraServiceClient service = this.GetService();
    service.GetDictionaryCompleted += 
        new EventHandler<GetDictionaryCompletedEventArgs>(service_GetDictionaryCompleted);
    service.GetDictionaryAsync();
}

void service_GetDictionaryCompleted(object sender, GetDictionaryCompletedEventArgs e)
{
    if (e.Error != null)
    {
        MessageBox.Show( e.Error.Message, "Service Error",MessageBoxButton.OK);
        return;
    }

    Dictionary<string, object> items = e.Result;

    StringBuilder sb = new StringBuilder();
    sb.Append(items["Field1"]);
    sb.Append(items["Field2"] + items["Field2"].GetType().ToString()) ;
    sb.Append(items["Field3"] + items["Field3"].GetType().ToString());

    MessageBox.Show(sb.ToString());
}

private PraServiceClient GetService()
{
    EndpointAddress addr = new EndpointAddress("http://rasnote/PraWebService/PraService.svc");
    BasicHttpBinding bind = new BasicHttpBinding();
    return new PraServiceClient(bind, addr);
}

The above surpringly works to marshal types in the dictionary down to the client even though the dictionary is Dictionary<string,object>. WCF does not like serializing generic object types however so results of type object or anonymous types fail outright. I suspect using these types as values for the dictionary too will fail.

Dynamic Data Access

The real issue here is that in lieu of a data model that can be used on the client side there’s no good data mechanism built into Silverlight that provides access to some dynamic data returned from the server. So say the server returns an arbitrary query where the user is allowed to pick the columns he wants to retrieve there’s really no clean way to return that data and present it on the client side. JSON serialization requires a type as an input to understand the structure and so a dynamic results can’t be represented. It’s possible to actually use JavaScript to create an object but even then that object comes back as a dynamic object which could only be accessed by Reflection (C# 4.0 dynamic oh where are you? <s>)

No DataSet Support

I know DataSets are kind of passé but when I really think about how this existing data engine works – DataSets with their weak typing and even with their update support are the perfect fit for this type of application. As many problems as DataSets have in typical pure data access scenarios, in internally controls disconnected scenarios Datasets have features that none of the newer data techologies have matched to date – mainly because DataSets allow for dynamic data to be returned and be accessed easily.

Alas – Silverlight has no support for DataSet/DataTable/DataRow. While looking at various third party components I actually ran into ComponentOne’s Silverlight Controls which include a Data assembly that provides a minimal set of the classic ADO.NET objects for Silverlight. But even with those the support is fairly limited (for example no support for schemaless XML or Diffgrams – the latter of which is kind of a bummer). Still for now that’s something to start with – if we decide to go this route I suppose it’s not terribly difficult to build my own abstraction that does support this functionality.

Something Custom?

I’ve also toyed with the idea of building a custom Dictionary type interface that I can deserialize from JSON which would basically allow me to use JSON from the server and get some sort of generic object back back on the client. Since the data is for the most part table based, object hierarchy isn’t really an issue either so it’d be fairly straight forward to build up something like this fairly easily.

Yes, C# 4.0 and DynamicObject would be pretty handy for this, but it’s going to be some time before that comes to pass.

Hmmm…

In some ways these issues are actually easier to work through in JavaScript/Html based interfaces. Because Javascript is a dynamic language it’s actually easier to retrieve JSON data from the server and use it on the client. The server can return arbitrary data and simply return it with the client having direct access to it. I suppose one could choose one of the dynamic languages (JavaScript, IronPython or IronRuby) on the client, but frankly that’s not really a good option either. The whole point of using Silverlight is to provide the richer, statically typed environment.

So I’m curious to hear what others are doing for their client side ‘data’ connectivity, especially when dealing with data that can’t be easily serialized back and forth between client and server. I suspect a lot of folks probably deal with raw data – manually parsed XML or possibly. If not what are you doing for data transfers? There are a many options but it seems that most of them have some shortcomings when it comes to effectively dealing with the data on both ends of the connection.

  I’ve posted my session samples and slides from last week’s Fall 2008 DevConnection conference. As always the conference has been great fun and I’ve been pretty happy with my presentations (except maybe the REST session which was just to short with the 15 minutes that were cut due to scheduling). This time around I had fairly easy sessions that I’d done a few times before which always makes things a little easier and I think the sessions went very well. Judging from feedback it looks like they were well received too…

Oddly though this year I didn’t feel terribly social – it seems like I was stuck in my room a lot working on sessions or various other things.Even the few times I got out it seemed the atmosphere with attendees seemed a little subdued – odd for a conference at Vegas. I’m just like Scott Hanselman pointed out in that respect: I don’t gamble, don’t drink or party much, and least of all do I like the cheesy excesses of Vegas. Not much that all that has to offer me especially on repeat visits. To me conferences are about hanging out with other developers but unfortunately there seemed to be very little of that at this conference. Even so I had a few interesting discussions at a few of the parties and with a variety of attendees after sessions. Frankly I really wish conferences tried to encourage more interaction between attendees and speakers by way of their scheduling instead of the separation of events and isolation with the ‘speaker room’ that seems to be happening so much at conferences that I’ve spoken at. <shrug>

Anyway enough bantering. Here are are the download links for my sessions:

Using jQuery with ASP.NET

This set of samples includes a number of different examples starting with the completed walk through client side example that demonstrates a wide variety of client selector operations, plus the interactive selection window and word search popups. This sample also includes a basic pulse plug in (shown), plus a Selector filter extension for :containsNoCase (not shown). There are a host of simple AJAX examples that take you through HTML fragment loading with $.load() including retrieving independent content, as well as a few variations of retrieving content from the same ASP.NET page and a basic example of returning JSON data from page output (which has many applications including MVC style apps). Then there are two identical samples that use WCF with jQuery – one that uses ASP.NET Ajax Web Service callbacks and one that uses only jQuery to access the same WCF service. Finally there are three larger sample applications provided: A WCF based StockPortfolio manager that allows picking stocks and adding, editing and deleting them from a portfolio view. Sample demonstrates a raw AJAX approach with all data loaded client side. Also demonstrates using jTemplates. There’s also a PhotoAlbum application that demonstrates a host of mechanisms for displaying and manipulating image display in a variety of ways. This is a reusable app that works simply with files in a directory that can be easily imported and updated. Demonstrates a number of plug-ins including Sortable and a custom Editable plugin used to edit captions in place. Finally there’s an Amazon Book Picker application which I use for selecting books from Amazon to display in my Web log. App allows selecting books from Amazon and using a window based layout allows adding, editing and updating of content. Demonstrates a more LOB type scenario and interaction of multiple floating windows of information. Also uses John Resig’s Microtemplate Engine.

This download also includes a jControls project which includes most of the West Wind Ajax Toolkit’s controls updated with jQuery. It includes a host of AJAX based utility classes including the ClientScriptProxy, ScriptContainer, ScriptVariables and other utilities covered here on this blog as well as a native callback control (AjaxMethodCallback) to make server callbacks easily with ASP.NET AJAX, DragPanel, HoverPanel and ModalPopup server controls as well as a rich client library of jQuery plug-ins that support the server side controls (although the client controls can be used independently of the server controls).

Download jQuery Slides and Samples

Using WCF for REST and JSON Services with ASP.NET

This set of samples includes a few simple REST urls that are directly accessed via URL demonstrating different result formats including XML, JSON, RSS as well as streamed responses. There’s also a second project that uses the WCF REST Starter Kit to publish a simple collection based list of items with basic display, list, add, update and delete support. This set also includes the WCF StockPortfolio example application I showed in the jQuery session, but done mostly with pure ASP.NET Ajax (with a little help from jQuery and a few helper functions). This example again is provided in ASP.NET AJAX and raw AJAX versions (implemented via jQuery) demonstrating different approaches to the same backend service to allow comparing behavior side by side. The examples in this session are not really self-explanatory – they rely somewhat on demonstrations and manipulation of the base code especially for the REST samples.

Download WCF REST Slides and Samples

Dealing with Long Running Requests in ASP.NET

This set of examples demonstrates a host of different operations to deal with long running requests. These examples take a very basic scenario of returning some data and displaying it with some delay. Different approaches are used to address various issues involved with slow running requests starting with user progress/working display options, moving on to asynchronous operations to reduce request times for IO centric tasks (Async Pages with Async Operations and Async Page Tasks). Then there are a several delegate and thread scenarios addressed from run and forget operations that can run in the background without feedback, to using a background scheduler for batching operations without tying up ASP.NET threads on seperate background thread. The final example then provides a comprehensive custom messaging solution that allows client and offloaded process server to communicate progress information while processing as well as pass complex data back to the client for working with or display. The messaging solution can be run inside of ASP.NET, in a separate process (sample uses a WinForm so you can see it run, but typically a service is more likely target) and finally running on a separate machine to offload processing completely of the current machine. The samples includes full source for the remote message manager.

Download Long Running Slides and Samples

Thanks for all those that attended my sessions in Vegas – I hope you got something useful out of them. I appreciate the many kind words many of you had afterwards… here’s giving back a little to you and the rest of the folks that didn’t make it. Enjoy.

Just got a funny picture from the Gorge from last summer that I’d thought I’d share. It’s one heck of a of a wipeout sequence of a backloop on a big day at Arlington last year in the summer:

Nice start but oops there go the feet out of the straps.


No feet = no good, so let’s hit the emergency exit button. Toss, toss…
 

Hey were are you going? Come back, come back!!! Gear took off another way. Airwalking home…

I remember this day and this wipeout on a backloop in particular – the board just  got away from me as I slipped out of the footstraps. I went one way (down) and the board went another. I particularily like the last picture with the horrified look, of the gear taking off even higher.

Fun… and no wipeouts like this are generally harmless although falling out of the sky from 15 feet or so can make for a bad landing at times. I’m used to it – there are more wipeouts than landings of these :-}.

Thanks to Richard Hallman who got these shots and also another nice sequence from a different day also at Arlington that I think is also extremely awesome and so memorable of last year’s epic sessions out at Arlington. And maybe not as embarrassing as the big wipeout above.

Big waves on the Columbia River at Arlington. This is NOT the ocean!

And yes – I’m proud to say I made that cutback and sailed away from it. 

Also a memorable day. It was blowing mid 40’s (mph) that day and it was late in the day – by the end of the day I was the only one left out on the water after a 4.5 hour session in this madhouse wind. I think that was the best day I’ve ever had in the Gorge… ah memories.

Bummer I didn’t get to see any days like this year in my short time in the Gorge. Next year.

In case you missed it: Microsoft released the second part of their support tools for jQuery in Visual Studio this week. The second part comes in the form of a hotfix for Visual Studio 2008 SP1 that provides built-in support for –vsdoc.js files to – when present – automatically provide Intellisense support in Javascript documents. In combination with the recently released jQuery Intellisense file that Microsoft released you can now very easily get jQuery Intellisense in Visual Studio.

Here’s what this now looks like when accessing jQuery elements in the page:

Note that you get Intellisense all the way down the chain – ie. not just on the first element. Notice also that plug-ins (draggable in this case) shows up as well in the list of ‘attached’ jQuery wrapped set functions.

Just as useful is Intellisense on individual members:

with all parameters and some fairly detailed information provided on methods, and their parameters although there are a few functions that have missing parameters (all the before/after/append/appendto/prepend/prependTo etc.).

Notice also that the jQuery parameter stored into an instance variable is also recognized as a jQuery instance and so Intellisense works on the win variable as well as an explicit $() function.

What you need to use jQuery Intellisense effectively

Here are all the things that you need to get the best jQuery support in the VS 2008 editor:

• Visual Studio 2008 SP1
  SP1 provides a number of enhancements to the Javascript Intellisense engine in Visual Studio and is the basis on which all the other enhancements run on. These improvements include faster parsing and some built-in knowledge of a few common Javascript libraries including jQuery to find and provide at least basic Intellisense support.
  
  
• jQuery Intellisense document file (jQuery-1.2.6-vsdoc.js)
  This .js file is an annotated version of the base jQuery.js that includes detailed Visual Studio style Intellisense information about each of jQuery’s functions and utilities. None of the code is changed – only comments have been added. This file isn’t meant to replace your original jQuery.js file, but rather to serve as a more complete Intellisense file during development. Not meant for production.
  
  
• VS 2008 SP1 Hotfix for –vsdoc.js Intellisense (KB958502)
  This hotfix enables any file with –vsdoc.js extension to act as an Intellisense background file for any referenced .js file. So if you have a script src referencing jquery.js all you have to do is have the jquery-vsdoc.js in the same folder as jquery.js and Visual Studio will automatically find and use the –vsdoc file for Intellisense. This works for jQuery with the above mentioned files as well as your own files.

This is all very nice and it works great.

I’ve talked about Intellisense some time back and I basically did something similar to my copy of jquery.js by providing a few key functions with Intellisense markup. So then when referencing the .js file I’d get the same Intellisense. With this support provided in Visual Studio it’s now become a lot easier to provide documentation in an external file simply by having a –vsdoc.js file for the same file.

The way this works is that Visual Studio first looks for the –vsdoc.js file, then a debug.js file and finally for the file you actually specified in the source.

In Practice

This works in basic script includes in the <head> tag or inside of the document inside of ASPX pages:

<head runat="server">
    <title>jQuery 101</title>   
    <script src="scripts/jquery.js" type="text/javascript"></script>
</head>

in script manager code:

<asp:ScriptManager ID="ScriptManager" runat="server">
    <Services>
        <asp:ServiceReference Path="~/MsAjax/MsAjaxStockService.svc" />            
    </Services>
    <Scripts>
        <asp:ScriptReference Path="~/scripts/jquery.js" />
    </Scripts>
</asp:ScriptManager>

or in script source files:

/// <reference path="~/scripts/jquery.js" />
/// <reference path="~/scripts/ww.jquery.js" />

Note that I prefer NOT to use the version number with my jQuery.js file to avoid later update renaming issues so my Intellisense file is actually jquery-vsdoc.js. Match whatever your main file name is version nunmber or not. Here’s what this looks like in a project in Visual Studio for me:

Note that I also have a jquery.min-vsdoc.js file in case I decide to embed the minimized version. Visual Studio is not checking for .min.js files and mapping them to the plain –vsdoc.js file – yet. So the following also works, but only if jquery.min-vsdoc.js is provided.

<head runat="server">
    <title>jQuery 101</title>   
    <script src="scripts/jquery.min.js" type="text/javascript"></script>
</head>

I spoke with Jeff King last week at PDC and there’s a chance that support for .min.js files might be added in the future natively. But even having the extra file should be no big deal because they are not used at runtime anyway so they don’t need to be deployed.

The Intellisense file and the hotfix in combination are a welcome addition to Visual Studio – it makes working with jQuery inside of the VS Javascript editor a lot easier because the documentation provided through the Intellisense interface is pretty rich and helpful in many situations.

Check it out if you haven’t already.

The Release/Debug Problem for Javascript

Although jQuery is specifically targeted here – this mechanism works with any .js file, so if you want to create Intellisense script for your own javascript files you can also store them externally. The downside is that maintaining comments in an external javascript code file is pretty much a maintenance nightmare – Intellisense currently needs to have a running Javascript file in order to interpret the comments. A better solution for this is eventually needed or else some built in tools that can strip comments automatically.

I’m doing the latter now through a custom script manager that minimizes and zips output, but really this should just not be necessary. ScriptManager does something similar but even it requires both debug and release scripts. Either way these  approraches work well only if you use resources or otherwise have ASP.NET serve the scripts rather than letting IIS optimize and do it. It’d be really nice if IIS natively could somehow participate in this process and provide minimization. I know I can do this with some ASP.NET code in a module myself, but IIS is already extremely optimized for the compression scenarios where it builds temporary files that are served with compressed data. This is something that ultimately would be nice to have native support for so developers can set a switch and not have to think about whether you’re working with release or ‘debug’ versions of files.

As I’m working on some of my demos for DevConnections next week I decided that some older demos I’ve had should be moved to Web Application Projects (WAP) rather than running on stock projects for consistency. I tend to use only WAP projects in production, but for demos I’ve often stuck with stock projects because they worked with Visual Web Developer Express. Now that SP1 has shipped though even VWD supports WAP projects (a big thanks for the ASP.NET team to making that happen!) and so there’s no need to use the stock project model any longer.

Other than consistency with other projects, there was also the issue of WCF Web Services behaving badly under stock projects. For whatever reason I still can’t figure out with stock projects WCF Services often simply stop working with a compilation error even though there have been no code changes. It appears the problem is related to the temporary file storage in the ASP.NET temp folder with copies of the App_Code assemblies getting out of sync with the service in some  way. There’s a slight fix for this in stock projects by turning batch compilation off:

<?xml version="1.0"?>
<configuration>
    <system.web>
        <compilation debug="true" batch="false">
        </compilation>
    </system.web>
</configuration>

This has helped make the problem less frequent, but it still occurs from time to time.  Using Web Application Projects this is not an issue because the full compile causes everything to be compiled into the same assembly so there’s no real chance of a version mismatch.

Anyway, so I decided I need to move this rather large demo project that contains many diverse examples from a stock to WAP project and as it turns out it took quite a bit of work to do it.

Converting from Stock to WAP in VS 2008

Prior to VS 2008 stock projects had an option to allow you to convert projects to WAP projects via a menu option – Convert to Web Application Project. That option is no longer available so the process has become fully manual.

Here are the steps that you should go through followed by a few gotchas you need to watch out for:

• Open your Stock project in a Visual Studio Solution
  
• Add a new Web Application Project to the Solution
  
• Drag and Drop all files from the Stock project into the WAP Project
  
• Remove the BIN folder (or don’t copy it in the first place)
  
• Manually add back ALL assembly/project references to the WAP Project
  It’s best to do this first to make sure that related files are found and any auto-compiled components (like Linq to SQL models or Web References) get properly properly translated when files are converted in the next step.
  
• Right click on the root node of the project and Convert To Web Application
  
• Rename APP_Code to something else if the conversion didn’t do it for you. I use Classes as my ‘code only’ folder
  APP_Code is an illegal folder name for a WAP project – if you don’t rename you’d end up with duplicate compiled classes which will cause problems. Ideally you shouldn’t have much code here – it’s best to put this sort of stuff into a separate project. Note that you can move any CodeBehind files (like Web Service, Handler or other ‘known ASP.NET files’) back into the actual content folders – no need to keep them in the App_Code/Classes folder since they’re easier to find with the actual content files.
  Note that Convert to Web Application should rename the APP_CODE folder and it did the first time I did this. Just now when I walked through this one more time to verify for writing it up however it didn’t create an OLD_APP_CODE folder. Further I couldn’t rename the folder at first. I ended up explicitly running Convert to Web Application on the old APP_CODE folder. After that I was able to rename it.
  
  
• IMPORTANT: Select all files that were in the old APP_CODE folder and set their Build Action to Compile.
  Files in the APP_CODE folder in stock projects are compiled by ASP.NET rather than Visual Studio so the default action for APP_CODE files in stock projects is content which doesn’t compile. When moved to a WAP project that same action is passed forward which means that Visual Studio is not compiling APP_CODE files by default. Make sure you switch the Build Action to Compile or else you’ll end up not finding the classes when compiling your project. This one threw me for a loop because I got compiler errors pointing at classes that I knew were in the project.
  
• Compile your WAP Project – rinse wash and retry
  There are bound to be a few compilation errors in your project when you do this. Pay especial attention to missing classes (check that the classes in question are set to Compile not as Content) or missing namespaces (make sure that classes other than pages have a namespace). Also make sure that you have all necessary assemblies referenced. You’ll likely get a bunch of errors and go through this cycle of compiling fixing and a host of errors until all references and classes are properly added. Read the next two bullets for a few more hints on possible compilation issues.
  
• Remove and Reattach Web and Service References 
  The Conversion imports Web and Service references but it attaches them into a separate folder. For me the Web References didn’t work correctly so instead I ended up removing them and re-adding them using the standard Web Reference/Service Reference tools. Note that in WAP this will cause Namespace changes – from only the name you assigned in Stock projects to the Project’s default namespace + the name you assigned. IOW, you’ll have a little bit of refactoring to do to fix these services.
  
• Linq To Sql Models
  My project had two Linq to SQL models and while both of the models transferred, they didn’t immediately compile. The problem is that the old designer file is detached and a new attached and somewhere in that process the actual class is not visible so that any reference to the model fails.
  
  
  The solution for me was to go delete both of the code behind files (the .designer files) both in the project and from disk. Then going into the model and resaving it. You’ll end up with the TimeTrakker1.designer.cs file which is odd, but works properly. The key is to make sure that the original file is deleted and removed.

So as you can see doing a WAP conversion is by no means a trivial task. I ended up spending a good two hours converting this project by the time I had everything back up and running as it did before. And that’s having done this before and having some idea what to look out for. The hardest part for me were the auto-building files – Web Services and the LINQ to SQL Models that just didn’t want to work after initial conversion.

Part of the problem was that the compiler wasn’t being helpful. I had the L2S model in the project for example with proper namespaces set on the model, yet the compiler failed to see the actual model’s classes. No error during model generation – I could see the classes in the model’s codebehind but the compiler failed to see the classes. When this happens the thing to check is to make sure that the Build Action is set properly and/or that there isn’t another file that is interfering with the namespace resolution.

The good news is that the issues are all related to file location/switch settings and once those were resolved the project just kicked right in and worked as expected. No further tweaking required. Personally I much prefer WAP’s more formal compilation approach and the reliability that comes from having a single code behind assembly that knows where are code behind code lives in one place instead of scattered through multiple temp assemblies as is the case with Stock projects.

I have a couple of other projects that I should do this to as well – not sure if I’m willing to put in the time again though. <shrug>

I’ve been working on my DevConnections demos today and as I was going through my demos I ended up significantly reworking a few of the samples and moving around projects. This actually went fairly smoothly but when I got to my AJAX StockPortfolio sample that mixes jQuery and WCF I got into a nasty mess of a problem that took me a good two hours to resolve. It turns out it was a typical problem of operator error on my part, but this still is one to write up and make others aware of.

My sample project consists of a WCF AJAX service that uses ASP.NET AJAX semantics for access from the client. This means the service is configured like this at the service level in the .SVC file:

<%@ ServiceHost Language="C#" Debug="true"

                Service="WcfAjax.JsonStockService"                

                Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory"                                  

%>

This tells WCF to publish the service by default using similar semantics as the old ASMX style services. Note the Factory attribute which is set to WebScriptServiceHostFactory which provides a pre-configured factory for typical MS AJAX style behavior. This factory means that all requests by default use WebInvoke() attributes with POST as the method to send data to the server and using wrapped message format that the ASP.NET AJAX client expects messages to be sent and recieved with. Using the factory makes the process very easy as you don’t have to create any web.config entries to configure the service although you can still do that to override particular settings.

With this done setting up the service is as easy as creating a class and plopping the [ServiceContract] onto it. Since this is an in-application Ajax service only I’m defining both the implementation and contract on a single class rather than seperate service contract interface and implementation class:

    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

    [ServiceBehavior(IncludeExceptionDetailInFaults = true)]

    [ServiceContract]

    public class JsonStockService 

    {

        private StockServer Stocks = new StockServer();

        private User User = null;

        [OperationContract]

        public StockQuote GetStockQuote(string symbol)

        {

            return Stocks.GetStockQuote(symbol);

        } 

        /// <summary>

        /// Returns a full list of items to the caller in the Items

        /// property for the PortfolioMessage

        /// </summary>

        /// <param name="userToken"></param>

        /// <returns></returns>

        [OperationContract]                

        public PortfolioMessage GetPortfolioItems(string userToken)

        {

            // Validate and get this.User instance

            this.ValidateToken(userToken);

            busPortfolioItem portfolioItem = new busPortfolioItem();

            IQueryable<PortfolioItem> items = portfolioItem.GetItemsForUser(this.User.Pk);

            PortfolioMessage msg = new PortfolioMessage

            {

                TotalValue = portfolioItem.GetPortfolioTotalValue(this.User.Pk),

                TotalItems = portfolioItem.GetPortfolioItemCount(this.User.Pk),

                Items = items.ToList()

            };

            return msg;

        }

    }

    /// <summary>

    /// Message Item sent to client. Contains Portfolio detail

    /// about a single item or complete portfolio

    /// </summary>

    [DataContract]

    public class PortfolioMessage

    {

        [DataMember]

        public decimal TotalValue { get; set; }

        [DataMember]

        public int TotalItems { get; set; }

        [DataMember]

        public PortfolioItem SingleItem { get; set; }

        [DataMember]

        public List<PortfolioItem> Items { get; set; }

    }

My service has about 20 different methods of varying complexity, but I ran into a problem with the GetPortfolioItems() method. When called from the service my client would receive an empty response from the server. No data returned, but no error either. No headers, no data – just a null response. This is a bit difficult to debug as you might expect and this is what ended up taking me 2 hours to figure out.

So what can I do to figure out what the problem is? As you can see in the method  above the result returned is a complex object. It’s basically a result message that contains a few pieces of information and all portfolio related method results all return this message object. The message object either has a single entity or a list of entites set along with a coupe of subtotals that require less code on the client.

First debugging step: Set a break point in the method and surprise, surprise the method actually completes properly. The code in the service fires to the server, but the the response still bombs with no result data. I checked the msg in the debugger and it’s fine no issues there.

So the problem most likely has to do with serialization. First to verify that the method is properly routed and working I returned null and that made it correctly all the way back to the client. No issue there. I then changed the methods WCF attributes to try and access it through a plain HttpGet:

[OperationContract]        
[WebInvoke(Method="Get")]
public PortfolioMessage GetPortfolioItems(string userToken)

which should allow me to access the request directly in the browser with a url like

http://localhost/jquery/stockportfolio/StockService.svc/GetPorfolioItems?userToken=2322121321

Here’s the unfortunate result:

The result is an incomplete page – or to be exact a page that didn’t return any output. It seems browsers handle this inconsistently. In FireFox I saw the above page as well as a browser based “Resource Could not be Found” error. Regardless, the bummer on this is that you get nothing back. No error, no message of failure – just no response at all.

In experimenting around with the problem method it seemed clear that the problem is with serialization. The question is just what. Next step for me was to enable WCF tracing and tracking errors. To enable tracing you can use something like the following:

<system.serviceModel>
  <diagnostics>
     <messageLogging logEntireMessage="true" logMalformedMessages="true"
       logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true"
       maxMessagesToLog="3000" maxSizeOfMessageToLog="10000" />
  </diagnostics>   
</system.serviceModel>
<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" switchValue="Error,ActivityTracing"
     propagateActivity="true">
      <listeners>
        <add type="System.Diagnostics.DefaultTraceListener" name="Default">
          <filter type="" />
        </add>
        <add initializeData="c:\projects2008\articles\jquery\traces.xml"
         type="System.Diagnostics.XmlWriterTraceListener" name="messages">
          <filter type="" />
        </add>
      </listeners>
    </source>
  </sources>
</system.diagnostics>

You can also use the WCF Configuration Tool which makes this process a little easier at least once you’ve set up the basic diagnostics settings. You can find this tool in Visual Studio off  Tools | WCF Configuration and then specifying the .config file.

You’ll probably want to just log errors which is by setting the switchValue to log just errors – otherwise the log will become very verbose with entries that’s difficult to read.

Looking at the logs turned out to be not very helpful other than confirming what I already knew: WCF was unable to serialize my message structure. I got a full stack trace of the error on the server, but no indication of what actually went wrong. Also there’s no indication on why there’s no error response to the client. It looks like WCF just quit processing the message after the serialization failure and doing an immediate output return.

Not very helpful.

At the beginning of this post I mentioned that the problem was operator error. I played around with different results from my message structure. Returning null, returning an empty message structure all of that worked. But as soon as I returned any entity data from my Linq To SQL model the failure would kick back in. It turns out when I copied the model somehow I failed to set the serialization options on the Linq to Sql Model:

Somewhere in the copy process or maybe when mucking around with the model I failed to set the serialization options for the generated entities. Setting the switch to Unidirectional turns on the [DataContract] and [DataMember] attributes on the generated properties of the generated model:

    [Table(Name="dbo.PortfolioItems")]

    [DataContract()]

    public partial class PortfolioItem : INotifyPropertyChanging, INotifyPropertyChanged

    {

        private static PropertyChangingEventArgs emptyChangingEventArgs = new PropertyChangingEventArgs(String.Empty);

        private int _Pk;

        public PortfolioItem()

        {

            this.Initialize();

        }

        [Column(Storage="_Pk", AutoSync=AutoSync.OnInsert, DbType="Int NOT NULL IDENTITY", IsPrimaryKey=true, IsDbGenerated=true, UpdateCheck=UpdateCheck.Never)]

        [DataMember(Order=1)]

        public int Pk

        {

            get

            {

                return this._Pk;

            }

            set

            {

                if ((this._Pk != value))

                {

                    this.OnPkChanging(value);

                    this.SendPropertyChanging();

                    this._Pk = value;

                    this.SendPropertyChanged("Pk");

                    this.OnPkChanged();

                }

            }

        }

   …

   }

Without this option the entities are not serializable. This makes perfect sense. Flog the developer for the oversight :-}.

However, what doesn’t make perfect sense is why WCF is failing so gracelessly in this scenario. Other exceptions such as user thrown exceptions in the code or errors in plain code actually return a proper error response to the client, but the serialization error does not.

Ugh, I’m finally back and settled from a long 3 week road trip. Ah, it feels good to sleep in my own bed again :-}. PDC last week was the last stop of the trip and as always it’s been an interesting experience. More than anything events like these are great to catch up with other developers and meeting people I’ve only seen virtually. I made face contact with a bunch of folks I only know through Twitter or comments on this blog. It’s always great to match a face with the message.

As usual PDC as an event was full of new technology and announcements. To me this PDC felt maybe a bit less revolutionary than previous ones in that a lot of the content covered has been previously announced or is even already in some sort of pre-release state available to the public. And that’s actually a good thing – I think it symptomizes Microsoft’s more open approach in product development which solicits early feedback and is generally good for all parties involved. For me this also worked out rather well – in the last half a year or so I’ve been pretty slow to play with new technology because I’ve been swamped with work and frankly have gotten a little tired of playing with the latest and greatest that’s not quite ‘there’ yet. A lot of stuff that’s been coming out of Microsoft in the last couple of years has been less than stellar and so for me the last year’s been mostly about getting back to the basics and working on core development rather than trying to gape at the latest and greatest.

Usually when I go to conferences I’m either speaking or otherwise involved in some official capacity that I rarely have time to attend sessions. This time around though – being purely an attendee – I had lots of time to go see sessions which has been great fun and even though I spent most days in sessions I wish I could have made to more sessions. Luckily most of the PDC sessions are actually online although finding them can be a little tricky. I’ve been making good use of this and catching up on additional content I missed.

PDC Impressions

So here are a few impressions from some of the sessions and keynotes I went to:

Windows 7
The second day’s keynote started off with preview of Windows 7 and well frankly it was a pretty bland presentation and show of new stuff. And yeah it wasn’t just me going by audience response and feedback. Bland yes, but maybe that’s a good thing. I’m starting to get into the mindset that less is more for Microsoft – the more Microsoft can focus on fixing/optimizing existing features across its products I think the better of we as users will be. I’d like to really see Microsoft focus more on fixing what’s there rather than keep building more and more crap nobody really needs.

As such the changes shown were fairly minor. The ones that stood out to me were native support for the VHD file format (used for Virtual PC Images) both for directly mounting virtual drives as well as booting from them. The remote desktop stretching over dual screens is useful too as is the better taskbar management. There will also be multi-touch support which will be cool if hardware vendors actually implement this stuff. Given how badly the tablet platform has fared over the years (no thanks to Microsoft’s inability to market this platform properly) I’m not having high hopes. I do think though that having touch support in screens would be pretty cool. Recently had a chance to play with an HP TouchSmart machine and it sure is nice to be able to work with the OS via touch in some situations.

Maybe the biggest news is that Microsoft is apparently doing some work to make Windows 7 run on less hardware (they showed a sub-notebook running with 1 gig of RAM running well with Windows 7) and improving core performance and startup. To me I don’t really care about anything else but a stable base platform, so if nothing else gets done but make sure that Windows 7 runs fast, stable and maybe has an Explorer that doesn’t crash and copies at a snail’s pace it’ll be a win.

All that said I think Microsoft’s goal needs to be polish the seriously tarnished image of Windows as a resource hog as well as the public image imposed by of all thing Apple marketing.

I personally don’t have any serious issues with Vista now, but I surely would like the resource usage in general to decrease. There are still too many times when even my dual core 2.4ghz machine is dragging because the OS performing some task in the background.

Windows Azure

Windows Azure was the big announcement at PDC this year. Azure is meant to be new hosted platform that provides scalable hosting of Web based applications. Azure can host traditional ASP.NET content as well as providing a host of service based components that are managed on the remote platform such as a blob and data storage mechanism, that effectively amounts to a remote file system. It also includes back ground worker processes that can be easily queued for background tasks, which is an interesting concept.

The big sell of the platform is the scalability – Azure runs on a load balanced platform that makes it easy to add new instances of applications to scale out easily and without having to reinstall and reconfigure anything. Azure effectively provides for packaging and replication of an application via what is called Fabrik Controller. This packaging also allows for smooth updates to staging and deployment servers which lets you push up a deployed app to a staging site, test it and then hot swap it across all configured instances.

A lot of what Azure does is pretty cool in concept. Certainly the packaged scalability is a nice and the main talking point of discussion I found with several other developers – if you’ve ever built applications that needed to span multiple machines you know what a pain it can be to scale out and make sure everything gets configured properly across machines.

However, in discussing with various developers I still am not sure just how applicable this sort of environment will be. Basically it’s NOT a typical ASP.NET hosting scenario where you can just park existing applications. The services deployed to Azure need to use the Azure data services (Sql Data Services?) for storage rather than a more traditional database. This means existing applications will have to be redesigned. The Azure data storage mechanism isn’t a SQL like store – rather the data mechanism is more like an object database that works by modeling types which get translated into single record entities in the database (like a reverse OR/M modeling wizard). It’s an interesting concept – you end up modeling your data as classes entirely and having the platform generate the data structures for you in the storage backend. The data stores are also accessible directly via REST endpoints so that any data stored is both application local and globally accessible which is also nice.  The format currently looks more like a ISAM type engine rather than a relational engine – there are no implicit relationships supported although nothing stops you from referencing foreign keys explicitly. The bottom line is that you have to work with the provided data model.

One concern I see is that servers deployed today often do more than just act as Web application servers. You may have background services running and code may be interacting with a wide variety of technologies outside of the basic Web application’s scope. All of this doesn’t look like it’s going to be supported on Azure at the moment. As it stands it looks like a platform for very specialized Web applications and that can buy into the very specific data format supported by Azure. I’m not clear how the data access actually works in applications – it looks like the access is all over HTTP and REST points, but I wonder if the data access on the live deployed server may be more direct? It’s hard to tell. Certainly I can’t imagine HTTP based data access scaling very well.

Overall the concept sounds intriguing, but I’m not sold on this idea. How many IT shops would really like to give up this much control over their platform and give it to Microsoft with the potential ability to control the pricing of the service? You’d be forever a slave to Microsoft’s pricing policies. Also how many sites actually need massive scalability? With the high end hardware available today it’s much less likely than it once was

The key thing that popped into my mind as I was watching the keynote and demos was: Lock in. Short of existing Microsoft fan boys I think this platform would be an extremely tough sell for Microsoft given that it’s based on all proprietary black box technology running on the server…

Keynotes in General

The keynotes in general were pretty dry and uninspired. Some of the speakers where painful to watch as they laughed at their own jokes – alone. There were a few highlights but most of the presenters where just spewing undefined marketing terms one after another. At a developer conference I found this pretty disappointing. Most of the presenters just sounded way too over-rehearsed. Heck even Scott Gu seemed to be just rushing through his presentation at a million miles and hour and his was probably the highlight of all the keynotes I saw. Don Box and Chris Anderson were entertaining but I’m not sure if this is a good ‘keynote’ presentation format either. It ended up feeling like filler more than anything. Hey but at least we got to see some code in their presentation (which without more context wasn’t all that useful either).

Honestly for a developer conference I would have hoped to have seen more detail on technologies. For all the time that was spent on Azure on the first day’s keynote I walked out of the room thing WTF does this really mean? It wasn’t until I went to the two follow up sessions that I had a reasonable idea.Not a good start to an idea. You know what they say “If you can’t define what it does in a few words…”

Luckily though the actual sessions were much better. This year I thought that the presentation skills of presenters were much better than in past MS conferences. A lot of presentations I saw were extremely professionally  presented with lots of time for questions at the end which is in stark contrast to the last PDC where there was lots of good content but often bad presentations.

C# and Dynamic Language Enhancements

Went to Ander’s Future of C# session and as expected C#’s main improvements are going to be based around dynamic language support. In the next version of .NET C# (and VB.NET) are going to provide services sitting ontop of the Dynamic Language Runtime (DLR). For C# the big improvement will be a ‘statically typed dynamic’ keyword. In essence the dynamic keyword allows assigning any type of variable and ‘dynamically’ access the members of that type as long as the members exist without having to hold a fully cast reference. What this means that you can access an object of type object and access its members directly without having to wade through Reflection.

The services that provide this functionality is calling on the DLR to provide the dynamic member resolving rather than direct calls to Reflection. The apparent advantages of this approach are that there can be better error handling, and improved performance through caching of Reflection type information as types are addressed. This functionality will be useful for any type of user provided code (plug-ins and the like) and especially useful for things like Interop with COM. Special attention has been given to the COM interop scenario since dynamic invokation there works a bit differently than for native .NET types. One additional improvement there is that the type hierarchy can be dynamically generated so no COM Interop Assembly needs to be generated.

VB folks must be snickering just about now because most of what the dynamic keyword functionality has been available for some time by using Option Expiclit Off, but still I think this is highly useful to get this capability in C# as well.

There’s also an IDynamicObject interface and an abstract DynamicObject class that can be implemented by developers to create objects that simulate Expando properties in C#. In effect this provides the ‘method missing’ functionality through explicitly implementing a class and intercepting all member access including access to members that don’t exist and returning a result that is effective conjured up out of thin air. The example Anders used was to implement a dictionary that uses properties instead of indexers to get and set values which is a little contrived but illustrates the point well. This can be quite useful in some situations.

I’ve talked to quite a few people who took the “So what?” at