Then I rebooted. The "Modify STS Reference..." and "Update federation metadata" menu items that are supposed to be added to the list of available options on an ASP.NET web application were gone. They were there before I rebooted but they were gone after. I also noticed something funny with the Identity training kit install. Every single directory and file in there was marked as "read only". I would unset the read-only flag, right click the file, get properties, and sure enough, it was still set to read only. WTF?

Turns out that when I download files from the big bad scary internet, Windows 7 automatically flags them as "bad content" and they are blocked. The permissions of those files are significantly less than those of files I put onto my computer via DVD or whatever. This is actually as it should be, and it's designed to keep me from doing horribly bad things to my computer.

I uninstalled the Geneva SDK and the Identity Training Kit. I then right-clicked each of the .msi files, chose Properties and then clicked the magic Unblock button. After this, when I installed the Framework SDK, the Visual Studio extensions remained after reboot, and the files created by the identity training kit didn't have weird permission problems and the certificates installed by the lab set up actually bound to the SSL port properly.

So, the moral of the story is this: If you're going to install an MSI that you downloaded from a trusted source (like MSDN or Microsoft Downloads or h0tpr0n.com), unblock it before you install just to make sure you don't run into any goofy permission issues.

First, some background on the Mayan calendar. The "long count" Mayan calendar is based, basically (I am oversimplifying a little bit), on interlocking wheels. You can think of these as gears where as the days pass, a bigger gear of seasons pass, which then slowly causes another bigger gear to pass. Finally, you end up with a gear that marks the passing of ages that marks the passage of a total of 26,000 years. There are 13 of these ages on the "big gear".

The Mayan long count calendar reaches 13.0.0.0.0 on December 21st, 2012. Does this mean that the world is going to come to an end on that date? Does this mean that a huge apocalypse is going to rip the earth apart in huge explosions and other hollywood-like demolitions? Are we all going to cease to exist as time itself comes to a crashing halt?

UM. NO.

What we're looking at here is the Mayan equivalent of the Y2K problem. The Mayans, when constructing their calendars and the wheels/gears/ whatever they call them - constructed them to mark the passing of 26,000 years. When you think about how long that is, its a ridiculous amount of time. They probably said to themselves, "Nobody is ever going to need more than 26,000 years on a calendar." Well, let's see. Where have we heard that mistake before? Oh yeah: No one is ever going to need 4 digits to store a year in a piece of computer software.

So if you're smart, you'll get people to give you all their worldy possessions on December 20th, 2012. Then, on December 22nd, 2012 - sell them all back at a premium. Call it the "sucker surcharge", a fee for being such a gullable moron that they believed the world was going to end because a civilization without the ability to predict the future basically ran out of storage space in their gear-based calendar system.

I personally am thinking of having an "end of the world" party on December 21st, 2012. I had one on Jan 1, 2000 and I'll be there laughing at the mindless masses as they cringe in expectation of doomsday. I should be able to pick up some dirt cheap real estate, too.

If you bought a book on Windows Azure that has already been released or will be released within the next month or two, it is out of date and completely irrelevant. PDC (along with the changes I'm going to outline below) will substantially change all of the Azure offerings.

I've trimmed a little bit because some of the breaking changes are fairly minor and don't have too much impact on developers. Here is the list:

• Portal address change. This is an easy enough fix and a simple find-and-replace if you've got any code that uses that portal address.
• Solution region migration. Some solutions when migrated to the new version of .NET Services might end up hosted in a different geographical region than before. This isn't all that big of a deal (for most of us).
• Queues Are Being Removed. This is huge. In the current version of .NET Services, you can use queues as a way of sending reliable, durable messages between the cloud and on-premise applications without the other endpoint being physically connected. This is a huge change. A new concept called Message Buffers are being introduced. I don't have all that much information on them but it looks as though the message buffers are essentially transient queues. You send a message to a buffer and it'll hang out in the buffer while the other end steadily pulls messages out of the buffer. A key point they make is that if you're looking for durable, reliable, persisted messages between service bus endpoints, you might want to look at using Azure Storage. As painful as it is to see queues go, I think this is a good move. Azure storage already has Queues, and they are robust and powerful. If the reason you were using Queues was to keep from overloading an endpoint with too many messages, the message buffer is your new tool of choice. If you were using Queues so that you could send messages while the polling end was offline, then you're probably going to need to concoct something involving an Azure Storage queue.
• Routers Are Being Removed. This is also huge, though slightly less huge than queues. The router concept never really "gelled" with me to begin with - I couldn't quite figure out how best to use it. Now that they're being removed and there will be some samples on how to do things like load balancing and targeted delivery, architectural decisions in this area should become easier to make.
• Relay Bindings are now secure (HTTPS) by default. You can override this behavior but there's very little reason to do so unless you are specifically trying to get your security information stolen.
• Service Namespace. Now instead of the solution name being the hostname of your *.servicebus.windows.net server, you will be able to choose something called the service namespace and have that be the hostname prefix, e.g. (namespace).servicebus.windows.net. This has low impact but is actually very useful.
• TransportClientCredentialType is being limited. Transport client credentials can no longer include X509 certificates, username/password combinations, or CardSpace cards.
• TcpRelayConnectionMode.Direct will be removed. This bugs me a little bit because way WAY back when Azure was first unveiled to the public, I remembered talking to someone who said that we'd be able to use the service bus to establish direct connections between two peers both of whom were behind firewalls. This is no longer a possibility, but I can see the reasoning behind it and, quite frankly, my particular use case for this feature was really niche-y.
• Service publishing feed now matches transport. This is handy and makes things a little more straightforward. For those who don't know, a service publishing feed is basically an Atom feed that shows all of the endpoints on your service bus service that have indicated they want their presence known publicly. In other words, I could hit the service publishing feed and get a list of all connected endpoints. That one ability is ridiculously powerful and is not getting nearly enough hype for the number of scenarios it enables.
• WSHttpRelayBinding has been removed. I'm not gonna miss this one bit as I never used it.
• WS2007FederationHttpRelayBinding removed. Again, not gonna miss it.
• Solution credentials replaced with issuer credentials in Access Control Service. This one is also quite big. Today, you can use a username/password combo, an X509 cert, or a CardSpace card to request tokens from the STS. As of Thursday, you're going to need an issuer credential (issuer key and issuer name). In addition, we're going to have to upload X509 certs to the portal to allow for SAML token requests. I will probably be doing a blog post on this once I get more information because this one is totally game changing and will halt development workflow as it stands now and totally change it after Thursday.

• WS-Trust STS replaced with Web Resource Authorization Protocol (WRAP) STS

    - Yes, I made this one gigantic. Why? Ding dong the witch is dead! The wicked witch is dead! WRAP is RESTful people. WS-Trust is EVIL people. Enjoy. We've all just been given a shiny cupcake with a frosting of awesome on top.
• Access Control Service data will not be migrated. This means if you're one of those crazy early adopters and you've already written a complete app on the existing ACS - get your data backed up and saved somewhere now. It will be deleted on Thursday morning!
• Access Control Management Portal is being replaced with a command-line tool. I know some of you might be thinking, dammit! But I see this as a good thing. It's an absolute pain in the ass to stop what I'm doing and click through 8 billion links (including the 500,000,000,000,000 redirects involved with a Windows Live ID login) just to go tweak some small setting. I could probably take 20 minutes to rig up a couple .cmd files to do regular ACM tasks that are specific to my app and be done with it. This is going to be a big productivity gain, even though we lose some flashy web-based GUI.

Here's the bottom line:

Windows Azure (including Azure Storage, SQL Azure, and .NET Services) is maturing. It is moving away from being an experiment and moving toward a product that can sustain regular income and regular usage and the 90% customer usage scenarios. As a result, they're going to break changes and add features and shut off lame or ineffective or almost-never-used features.

Can't wait to get my hands on the new bits Thursday.

Conveniently enough, if you follow the tips in the previous blog post, you would have already created a local copy of your SQL Azure database. The "trick" (not really a trick at all, just not immediately obvious) is to point your EF or LINQ to SQL Visual Studio projects at your local database. This will give these mappers the schema and relationship information they need in order to create the appropriate conceptual<->relational mappings.

For LINQ to SQL, all you need to do is replace the connection string that it adds to your app.Config file with the connection string supplied by the sql.azure.com portal. Remember to include your password in this connection string because the portal copies a version of this string to your clipboard with the password of myPassword. At this point you should also be thinking to yourself, "Wow, I just put a cleartext password in a .config file. It's a really good thing that this code isn't going to sit on someone's desktop and will be protected in the cloud."

With Entity Framework, the connection string is a little more complicated. There's some entity stuff in there that points to the various model definition files in the project and then there's an embedded connection string. Replace the embedded connection string (take care to maintain the escaping of nested quotes, etc) with the one the SQL Azure portal supplied and change the password to reflect the right password.

At this point you should have been able to generate a model from your local database and then change the connection string so that the actual data comes from the cloud database. It might seem a little inconvenient but it isn't really all that bad. It just adds a few extra steps to your SDLC when you need to change the schema of a live application.

The feeling I got when I ran my first LINQ to Entities query against a cloud-based SQL Server database was overwhelming. Sure I love new technology as much as the next guy, but the possibilities that are being opened for developers by Windows Azure and cloud computing in general are so numerous it's hard to contain myself.

This is a damn good time to be a developer.

To do that, you'll go to sql.azure.com and follow the directions to sign in - if you haven't already supplied the invite key you'll need to supply it after you sign in the first time. Select your project and click on it. At this point you'll see a pretty sparse management screen with two tabs: databases and firewall settings. On the database tab, create a new database (its up to you whether you create a 1GB or a 10GB max database). After you've created it, you'll be able to click the Connection Strings button to get an ADO.NET connection string for the database as well as an ODBC connection string.

That's great, but how do you manage the schema? Can you just fire up SQL Server Management Studio (SSMS) and right-click on the "Tables" node and create new tables the old fashioned way? Unfortunately, no. You cannot connect to SQL Azure directly with SSMS the way you can to a regular SQL Server instance.

To connect to SQL Azure with SSMS:

1. Open SSMS (this part should be pretty obvious)
2. When you are prompted to connect to a database, cancel that dialog.
3. You should be left with an empty management console. Click New Query.
4. For the server name, take the fully qualified host name from your SQL Azure connection string. It should look something like (blah).database.windows.net.
5. Choose SQL Server Authentication. Supply the username and password that you used for your database. Parts of this information should also be visible on your connection string.
6. Click on the Options button on the bottom right of the dialog box
7. Set the database name, manually, to the name of your database. It will not show up in the drop-down list.
8. Force the network protocol to be TCP/IP (this step may not be necessary, but I do it out of habit)
9. Make sure Server type is set to Database engine (this is the default, but might not be if you use SSMS for more than your average bear)
10. Now you can click Connect.

At this point, if everything worked well, you should FAIL to connect to SQL Azure :) You should get some horrid message about a connection from your public IP address not being allowed. This is because this version of SQL Azure has a built-in firewall and, by default, it doesn't allow anything through.

Go back to the sql.azure.com portal and click on the Firewall Settings tab. Check the Allow Microsoft Services to Access this server box. Click the button to add a new record. At this point it will conveniently show you what it thinks your public IP is so you can create a new rule to allow your IP through. Keep in mind this is only required to allow your home computer to access your SQL Azure server. If you have checked the Allow Microsoft Services... checkbox, then connections from within the Azure fabric (like an ADO.NET call from inside an ASP.NET app in an Azure Web Role) will pass through the firewall unhindered. This firewall is specifically to keep the communication safe and give you a "DMZ-like" experience where only the people (IPs) you trust will be able to hit that server from outside the Azure cloud fabric.

Now, after adding the firewall rule, you will need to wait up to 15 minutes or more. When I did it, it took over 20 minutes. The reason is that the portal where you hit the submit button is not the same physical machine as your SQL Azure server. It takes a few minutes for your new firewall rule to make it over to the actual data center where your SQL Azure server has been provisioned (at least that's my best guess to explain this delay). So don't be alarmed if 10 seconds after you add the firewall rule you still can't get into your database.

Now you are free to write T-SQL until you are blue in the face. What's that, you don't love hand-writing T-SQL schema change scripts without any assistance from an IDE? Neither do I. This is why I created a Visual Studio 2008 "Database Project" that references a local database with the same schema as the one I want to have in the cloud. This is useful for multiple reasons. The biggest of which is that with a "Database project" I can version control my scripts. Secondly, I automatically gain the benefit of a local development copy of my database. Finally, this allows me to, from within VS, right-click any schema element and script it into the project. I can then open that script, do some cleaning up, and then execute that script in the aforementioned SSMS query window. The cleaning up I'm referring to means stripping out the plethora of extraneous options on the ends of the CREATE TABLE statements and things like that. A lot of those options aren't available in SQL Azure so just strip them out after you script the table, proc, view, whatever. It's a pain in the butt, but it's certainly better than having to hand-craft all that T-SQL if you aren't into that sort of thing. I know some developers that like to get all kinky with their T-SQL and would never let VS script it for them. Me, I like to wear protective gear when I talk to the database schema so letting VS give me a head start suggestion as to the script I should run on SQL Azure works just fine for me.

Instead of having to maintain simple validation logic in two places (your business classes and your jQuery code), you can now use the Data Annotations attributes and metadata "buddy" classes to decorate your models. Those decorated models will automatically generate the appropriate jQuery code to enforce all of your validation rules on the client side before the form is ever submitted. Let's see how this works.

First, we need a model class. Let's do something simple like Customer:

public partial class Customer
{
    public string Name { get; set; }
    public int Age { get; set; }
}

This is great. I love the fact that it doesn't look ugly and view developers can look at it and immediately know what fields are available and they don't need to sift through a pile of persistence garbage or validation logic. You might have noticed that I've made this class partial. The reason I'm doing this is because I'm going to create another file called Customer.metadata.cs. There are other samples on the web that don't do this, but I like cleanly separating the definition of my model from the validation logic for that model. Here's a look at my Customer.metadata.cs file:

[MetadataType(typeof(CustomerMetaData))]
public partial class Customer
{
    class CustomerMetaData
    {
        [Required(ErrorMessage="You must supply a name for a customer.")]
        [StringLength(50, ErrorMessage = "A customer name cannot exceed 50 characters.")]
        public string Name { get; set; }
    }
}

What I've done here is used a metadata "buddy class" (that's what posts from Scott Guthrie and Scott Hanselman have been calling them, so I'm sticking with convention here). This buddy class is a placeholder for all my validation logic attributes and the runtime will then merge all this stuff onto the actual model. MVC 2 will then examine the model and , with a few lines of code in the view, generate the appropriate jQuery client-side validation logic.

In your view code, add the following 3 script declarations:

Finally, somewhere before the start of your form tag, add the following markup to the view code:

<% Html.EnableClientValidation(); %> 

This will invoke the code that reads through the strongly typed model for your view, figures out all of the validation logic that applies, and generates the appropriate jQuery code.

While you could write your own jQuery validation code if you felt like it, using data annotations and MVC 2, you no longer have to maintain your validation logic in two places. The attributes apply to a single view model and all you have to do is change one of those attributes and the generated jQuery code will change as well. This is a huge timesaver and promises to dramatically increase overall productivity of developers building large-scale MVC 2 applications, especially LOB apps with lots of data entry forms.

So let's say you have a DateTime property on your model called MeetingDate. Rather than make every single view write its own (potentially contrasting!) code to render dates in view mode and in edit mode, you can now do something like this:

<%= Html.DisplayFor( m => m.MeetingDate ) %>
<%= Html.EditorFor( m=> m.MeetingDate) %>

The DisplayFor helper will look at the data type of the thing you're looking for and try and figure out how to render that item. If you don't override convention, it will look in the Shared/DisplayTemplates folder for a DateTime.ascx control. If you want the display template to be specific to a certain controller, it can also look under the Views/(ControllerName)/DisplayTemplates folder. This same rule applies to EditorFor. It will look for the special EditorTemplates folder to try and find a suitable control. By "control" here I'm actually referring to a partial view since technically there are no controls in the traditional ASP.NET sense in MVC.

There's another HTML helper that you can use in your top-level view to invoke the partial-view location heuristics for an entire model just by doing:

<%= Html.EditorForModel () %>

This will examine the data type of your strongly-typed view and go look in an EditorTemplates folder to find the appropriate partial view.

Finally, there's another way you can supply hints to the templated helper system. That's through the use of the UIHint attribute. The UIHint actually allows you to decorate your view model (you are using an isolated view model and not working against persistance objects directly, aren't you?) with hints as to which editor should be used. This is fantastic for drop-down lists because the underlying value of a dropdown list is usually the ID of the lookup column, which is just an Int. You can't infer from Int that you want the Country dropdown vs. the State dropdown vs. the Weapons dropdown. To tell the engine which template you want, you can use the UIHint attribute as follows:

[UIHint("CustomerStatusDropDown")]
public CustomerStatus CustomerStatus { get; set; }

Where CustomerStatus is another view model object that you've got with a Name/ID pair (In my case I did it this way to accomodate the data coming from an ADO.NET Data Service). When you do Html.DisplayFor on this particular property of this particular class, it will override the normal algorithm and go look for a DisplayTemplate called CustomerStatusDropdown.ascx. When you do Html.EditorFor, it will look for a file called CustomerStatusDropDown.ascx but in the EditorTemplates directory. This allows you to simply, cleanly, and elegantly control how you display and edit lookups.

If you want, you can control the template selection directly from the EditorFor method call:

<%= Html.EditorFor ( cust => cust.BirthDate, "DateTime_jQuery") %>

You might use a pattern like this in order to allow some pages to edit date/times with a jQuery picker instead of a traditional date/time picker. The possibilities are endless.

The reason why I'm blogging about this now, only a few days after Beta 2 comes out, is because I think this way of arranging your UI is so, absolutely, positively crucial to a clean, elegant, easy to maintain ASP.NET MVC application that everybody should be getting in the habit of using templated helpers now so that by the time VS 2010 hits RTM, the use of templated helpers will be old hat and we'll all be one step closer to ridding the world of "tag soup" forever.

p.s. If you invoke some of these EditorFor and DisplayFor helpers without actually having a suitable control in the EditorTemplates or DisplayTemplates directory, you might find some pretty interesting results. For example, if you do EditorForModel, and there isn't a control for that data type in your EditorTemplates directory, the system will actually use Reflection. It will sift through the public properties of your model, and for each property it will do the equivalent of invoking EditorFor and LabelFor on that property. In short, it will scaffold you up a "best guess" editor for your entire object. The reason this is in a "p.s." is because such scaffolding is great for smoke testing, but rarely lasts long.

• ASP.NET MVC 2 is now built right into the installation. Finally we get convergence of the ASP.NET MVC project and VS2010 tools. Up until now, MVC 2 was only working on VS2008 which sucked for us early adopters of VS2010 and MVC!
• Azure Tools - there's a project type in here that when you create a new project of this type ("Cloud Service") it tells you how to get going with Azure. Current versions of Azure only run on .NET Framework 3.5 SP1 and right now I have enough available virtualization and memory to not mingle. So right now, I'm not going to even bother trying to get Azure working on VS2010 until I know the Azure back-end is running .NET Framework 4 and there is native, in-IDE tooling for VS2010 like there is for VS2008.
• EF4 - All kinds of ridiculous stuff here. Be sure to check out the Entity Framework blog for information on what's new in Beta 2.
• WCF and WF - Workflow services, Workflow in general, and WCF overall have recieved quite a bit of overhauling and fine tuning since beta 1. Make sure you try workflow services with content-based correlation and service discovery - all very awesome stuff.
• Astoria with Projections - the same goodness that you've been enjoying with the 1.5 CTP2 of Astoria (including projections!!) is available already inside VS2010.

As I said, there are a billion other things available in VS2010 Beta 2 and there are a billion other blogs that have more detailed information on it so I'm not going to duplicate that stuff here.

Bottom line is this: Go grab VS2010 from your MSDN subscription now, or wait until they release it to the public during PDC. Start messing with it and start playing with it.

One of the new things that you can now do server-side via the new CTP2 URL syntax is projections. Projections actually allow you to control the shape of the output coming back. You can specifically choose which properties on the entity you want. Even more awesome is that this can be controller hierarchically. So if you bring back an Order entity and you include all of the OrderItem entities for that order, you can tell the server that you only want the customer for the Order and you only want Quantity and Price for the order items.

To perform a projection on the URL, you just use the $select parameter, like this:

blah.svc/Orders?$select=OrderID,Quantity,Price

And to control the shape of hierarchical data:

blah.svc/Orders?$select=OrderID,Quantity,OrderItems/Price,OrderItems/Quantity&$expand=OrderItems

At this point when I saw this I started having convulsions of pure joy. The main reasons being that every ADO.NET Data Services URL query will output either AtomPub or JSON. This means I can get only the columns I need and give them to my Ajax calls. Then I noticed that support for the new projections is actually in the Astoria client library as well, allowing me to write the following query:

var q = from order in ctx.Orders
        where order.Price > 300
        orderby order.Price descending
        select new { Price = order.Price, Quantity = order.Quantity };

This will translate into an Astoria query that filters, sorts, AND projects all on the server side, leaving me with a network footprint that only transmits the information I want and nothing else. This is a godsend if you have entities with huge amounts of columns but each individual query might only need to use 1 or 2 of those columns at a time.

And now, if this wasn't ridiculous enough, you can actually perform updates using the projected objects, AND those updates will ONLY transmit the information necessary. For example, if I only want to change an order's price and I got the price from a projection, I don't need to carry the entire order payload across the wire in order to commit the change:

order = q.First();
order.Quantity = order.Quantity + 42;
svc.UpdateObject(order);
svc.SaveChanges();

This will figure out that the only thing changing is the Quantity field and it will ONLY send that information. After discovering the combination of projections and the efficient round-trips of Astoria, this is when my head exploded.

If you have a multi-tier scenario and you're using an Entity Data Model (EDM), then you should definitely look into using ADO.NET Data Services to expose that model via services because now with projections, you can really do some unbelievable stuff. All that garbage code you used to have to generate to convert between DTOs and ViewModels and Entities and back again? You can delete ALL of that crap.

I've said it before but the folks working on ADO.NET Data Services deserve a medal. If you see a member of that team, buy them a beer. You have no idea how ridiculously complicated and difficult it is to write code that supports arbitrary projections like this. I'm pretty sure every time you run an Astoria query with projections, an Angel gets its wings.

Reference data is data that rarely changes, is frequently queried, and shows up in multiple places throughout the application. This might be anything from the list of companies currently trading on a particular stock market if you're building a financial web application or things like the list of countries, states, cities, counties, tax rules, and shipping tables if you're doing fulfillment of orders online.

The problem is we rarely think about reference data ahead of time, so what usually happens is our strategy for handling reference data becomes an ugly pile of spaghetti and we have some controls doing their own queries to get reference data and some pages doing it and some services - it's a mess.

It would be awesome if we could have our controller methods declare ahead of time what reference data the view is going to need and then the view will simply have that data when it renders - completely abstracting the manual fetching of reference data for dropdownlists and other lookups. This centralization of reference data handling also gives us the ability to control the cache lifetimes of reference data items individually.

Thankfully ASP.NET MVC lets us do this easily. All we have to do is create our own action filter attribute. For example, let's say we've got a Customer controller and we're building the Edit(int id) method. Our customer view model objects are normalized enough so that they have IDs on them for country, customer type, and membership type (totally contrived examples, don't diss my domain knowledge of CRMs...). A sample edit method might look like this:

[RequireReferenceData(ReferenceDataKey = ReferenceDataKeys.Countries)]
[RequireReferenceData(ReferenceDataKey = ReferenceDataKeys.CustomerTypes)]
[ReqiureReferenceData(ReferenceDataKey = ReferenceDataKeys.MembershipTypes)]
public ActionResult Edit(int id)
{
    Customer cust = customerRepository.GetCustomerByKey(id);
    return View(cust);
}

The beauty of this approach is that anyone reading your code will immediately know that the view being rendered is going to depend on having 3 different types of reference data lists made available, as well as the core Customer object itself. Compare how easy this is to read and maintain to a classic .ASPX page where you might have the countries lookup being loaded by a custom dropdown box and the customer types lookup being loaded by the page and the membership types being loaded by yet another pile of spaghetti elsewhere.

To create the RequireReferenceDataAttribute class, all you need to do is inherit from ActionFilterAttribute and override the OnExecuting method. In this method you would just fetch the reference data and store it in the ViewData dictionary like this:

context.Controller.Model.ViewData[ReferenceDataKey] = (data fetched from elsewhere...);

And then in your view you can do something like this:

<%= Html.DropDownList("CustomerTypeId", 
(IEnumerable<SelectListItem>)ViewData[ReferenceDataKeys.CustomerTypes]) %>

And you're all set. The main moral of this story is to never underestimate the power of action filters. With ASP.NET MVC, if you want your intent to be more declarative and you want your code to be more readable, chances are you're only a few lines of code away from where you want to be.

In the sample I'm going to illustrate in this series of blog posts, I'm going to create a customer service helpdesk application. There will be a single workflow at the core of the application - the customer issue workflow. A customer calls complaining that their widget is completely, horribly broken and the customer service rep starts a new issue. The issue then persists forever while communciation goes back and forth between the customer until finally one of the communication types is a "close ticket" type. This is a really simple workflow, but should be similar enough to things that people do in the "real world" that the sample won't feel contrived or too "hello world"-ish.

Some of the stuff that I'll be showing here will look very similar to the WCF/WF 4 Training Kit. The main issue I have with that training kit is that there's too much "magic" in it. By "magic" I mean stuff that was pre-created for you (like service references consuming the workflow services), so in this sample I'll walk you through how to create all that magic.

So to get started let's create a Sequential workflow and host it in a console app. I would normally host it inside IIS but I couldn't figure out how to get the HTTP metadata exchange stuff to be published on the .xamlx endpoint. To do this, open up Visual Studio 2010 Beta 1 and create a new project of type Sequential Workflow Console Application. Delete the Sequence1.xaml file and add a new sequential workflow to the project called SupportCall.xaml. From the toolbar, drag over a ReceiveAndSendReply activity from the Messaging category. This is the activity that is going to allow your workflow to receive a message via WCF and then do something with it.

Before we can do something with the message, we need to know what the message looks like. To do that, I added a class library to the solution and created a data contract class that looks like this:

[DataContract]
public class Customer
{
[DataMember]
public string FirstName { get; set; }
[DataMember]
public string LastName { get; set; }
[DataMember]
public string CustomerID { get; set; }
[DataMember]
public string Address1 { get; set; }
[DataMember]
public string Address2 { get; set; }
[DataMember]
public string City { get; set; }
[DataMember]
public string State { get; set; }
[DataMember]
public string Zip { get; set; }
}

Add a reference to the contracts assembly from your workflow project and build the solution. Now you can modify the messaging piece of your workflow to accept messages of type Customer. To do this, you need to add a variable to the workflow.

Click the "Variables" button on the bottom left of the workflow designer surface and add a new variable named CurrentCustomer. When you choose the data type, click "Browse" and then type "Customer", you should find under the "Referenced Assemblies" tree node the customer class from the contracts assembly. When you've created this variable, your variables area should look something like this:

In order to receive data from a message, you need somewhere to put that data. In a workflow service, that somewhere is a variable. Now you can go and click on the Receive-Reply sequence and edit it so that the operation name is StartIssue, the service contract name is CustomerIssueService and the Value property (where the message value is stored) is the name of the variable we just created: CurrentCustomer. When you're done editing the receive-sendreply sequence, it should look something like this:

I modified the sendreply portion of the sequence and set the value to the following:

"A new issue has been created for " + CurrentCustomer.FirstName + " " + CurrentCustomer.LastName

If you're curious, the syntax for rules and expressions inside WF4 is ... *drumroll* ... Visual Basic!! This is important to keep in mind if you're in there editing rules and the rest of your application is written in C# - your stuff won't work if you start throwing C# syntax into the expression editors.

We're almost there. At this point we now have a workflow, but our solution won't compile because our Program.cs file from the stock VS template is full of junk related to launching Sequence1.xaml. Modify your Program.cs file to look like this:

namespace CustomerSupport.Services
{
    using System;
    using System.Linq;
    using System.Threading;
    using System.Activities;
    using System.Activities.Statements;
    using System.ServiceModel.Activities;
    using System.ServiceModel.Description;


    
    class Program
    {
        static void Main(string[] args)
        {
            string baseAddress = http://localhost:8081/SupportCall;

            
            using (WorkflowServiceHost host = 
              new WorkflowServiceHost(typeof(SupportCall), new Uri(baseAddress)))
            {
                host.Description.Behaviors.Add(new ServiceMetadataBehavior() { HttpGetEnabled = true });
                host.AddDefaultEndpoints();

                
                host.Open();
                Console.WriteLine("Customer Support Service listening at: " + 
                  baseAddress);
                Console.WriteLine("Press ENTER to exit");
                Console.ReadLine();
                host.Close();
            } 
         }
    }
}

Now we should be able to compile and when we run our console application (requires VS to be elevated!) we should see the message indicating that customer support service is running. We can quit the app now.

To create the client (we'll be making a better client in future blog posts) let's just create a new console application and add a reference to the contracts assembly. In order to add a service reference to the workflow service, you have to launch the workflow service console app from the command prompt because you can't add service references while Visual Studio is currently debugging something.

Modify the Program.cs for the client console application (after adding a service reference) to look like this:

static void Main(string[] args)
{
    CustomerIssueService.CustomerIssueServiceClient svc = 
      new CustomerSupport.Client.CustomerIssueService.CustomerIssueServiceClient();

    Customer cust = new Customer();
    cust.FirstName = "Bob";
    cust.LastName = "Asdf";
    cust.Address1 = "666 Evil Lane";
    cust.Address2 = "";
    cust.City = "Hades";
    cust.State = "NJ";
    cust.Zip = "99999";
    cust.CustomerID = "ASDF";
    string response = svc.StartIssue(cust);
    Console.WriteLine(response);
    Console.ReadLine();
}

Now you can run the application and you'll see a line of text indicating that a new issue has been created for customer Bob Asdf. In the next blog post, I'm going to walk through adding more steps to the workflow to make it more realistic, including adding another web service call in the same service that uses correlation so that we can progress multiple instances of multiple workflows and correlate the messages to the right workflows based on message content.

Some things to keep in mind as you wait eagerly for the next blog post are how the naming of the service contract and operation name affect the names of the methods and proxies created when you add a service reference to the workflow service.

http://www.caffeinedi.com/2009/09/29/how-to-build-your-first-azure-powered-asp-net-mvc-app/

I'm using Blob and Queue storage for several things and I've actually got a couple of projects going right now where I'm using binary serialization for both Blobs and Queue messages. The problem shows up when you try and use the BinaryFormatter class' Serialize method. This method requires the Security privilege, which your code doesn't have when its running in the default Azure configuration.

And change it to this:

You'll have to do this for your WorkerRole as well if you want your worker role to be able to do this kind of serialization. That's it...Now when you run your application it will have sufficient privileges to perform the serialization/deserialization to keep your storage and transmission payloads as small as possible.

Your application has quite a bit of administrator-only functionality so, after you've been using it locally for a while you put in some safeguards to block access to the admin areas unless the user is in the Administrators role. That's awesome and ASP.NET and ASP.NET MVC both have some really great code shortcuts for enabling this kind of situation and you can make yourself an administrator pretty darn easily.

So you're an admin and you deploy your application to staging and you go to run it and you try to log in. Whoops your account isn't there. This is because for the last couple of weeks you've been running against your local SQL 2008 (or SQL Express) database and you forgot that you did a few tweaks to make yourself an administrator. In the last couple of weeks you removed the code on the site that allows users to self-register since your application is an LOB app with a manually administered user list.

There is a built-in tool that comes with Visual Studio 2008 that allows you to do site administration. In a non-cloud environment, this was a great way to do things because you could simply configure your providers and then click "Project" and then "ASP.NET Configuration" and you would be taken to a Cassini-based website that allows you to add/remove users, manipulate roles, etc. It was great.

The problem is that when you run an Azure application locally, you're running the Role, you're not running the ASP.NET application. This means that when you launch (at least as of last night when I tried this) the ASP.NET configuration site, you're going to get a pile of errors all stemming from the fact that information contained in your service configuration file wasn't found and you'll get other errors because the local fabric doesn't get initialized when you don't start the app through the role.

So what can you do? If you can't use the admin site  then how do you create an admin user that can then create more users? Lots of really talented people have contributed to the MVC community including a fully functional admin site that uses the membership provider to administer users, etc and you can use this if you want. What I've been doing, however, to ensure that I'm never left without some form of administrative access to my sites is by creating a root account.

What I do is in the service definition I declare three settings: RootAccountName, RootAccountPassword, AdminRoleName. I then have code in my application startup that will use the Membership API to create this user with the given password and add them to the Admin Role (and create that role if it isn't created already). This guarantees me that any time I do a fresh deploy or even wipe my storage account that I'll still be able to login as an administrator to stage or production and I can keep the root account name different between stage and production.

Again, Azure development is awesome and shares a lot of similarities with traditional ASP.NET development but some things (like the built-in site admin tool) don't work out of the box via the cloud and so we have to keep these things in mind as we build applications for the cloud.

For example, if you look at just about 99% of the Azure samples, blogs, and other reference material, you will see stuff that looks like the code below, sitting right inside web.config:

<add key="TableStorageEndpoint" value="http://foo.table.core.cloudapp.net"/>
<add key="QueueStorageEndpoint" value="http://foo.queue.core.cloudapp.net"/>
<add key="BlobStorageEndpoint"  value="http://foo.blog.core.cloudapp.net"/>
<add key="AccountName"   value="foo"/>
<add key="AccountSharedKey"   value="...lotsa stuff..."/>

If you were to make assumptions about this, one might assume that you should be putting stuff like this in your web.config file even when you go to staging and production. NO! Stop right there!! This is not how Azure configuration settings are supposed to work!

Equally prevalent in the samples you will find calls to methods like GetDefaultTableStorageAccountFromConfiguration. there is actually a bit of useful logic going on in here that might not be immediately obvious.

This method is going to make attempts at getting configuration information from multiple different locations. It will check the web.config/app.config file, but it will also check your service configuration file. The most important thing to remember about this file is that it can be edited directly from the Azure portal. This means that you can deploy your application to stage and then go in and edit the service configuration file to change all the endpoints to your staging endpoints, then activate your app.

The reason this is important is because you never, ever, ever want to include your Azure key information in your web.config file, especially if you're posting on forums or sharing your code with other people. This is because if anybody gets your account name and shared key combination, they have full access to your Azure storage account and can basically run amok all over your data.

So, how do you know when you use a service configuration setting vs. a web.config setting? Here's a quick rundown:

• If you need to be able to edit the information after deploying, it must be in service configuration and not in web.config
• If the information only changes once per full deploy to production, e.g. it's version bound not environment bound, you can leave the setting in web.config

So, for example, in a typical Azure application, you might store the names of your queues and tables in web.config (because they should rarely change and will remain the same between stage and production), but you'll put the endpoint information related to your Azure Storage account in the service configuration file.

Hope this helps. The key thing to remember is that Azure service configuration can be a really powerful tool if you know its there... it can also screw you up if you forget its there :)

The main thing that I get from this picture is a feeling of awe. I mean, it's Saturn for crissakes... and we've got a machine flying around that planet, taking pictures that can be assembled into the massive image in the link and sending those pictures across the solar system back to machines on Earth. Just take a deep breath and stop and think about that for a minute. Today we take virtually all things technological for granted - nobody notices that our phones are using more technology today than the super computers that launched man to the moon 40 years ago. Nobody seems to care that when we were younger, the most awesome kickass gaming rig was a 486 DX2 that ran at 66Mhz. 66Mhz! And that was really just a trick, it's clock speed was really only 33Mhz.

So now on any given day I can use the Internet, wirelessly, from a coffee shop, on a 13" device that doesn't need to be plugged in all the time... and I can use that Internet to download an image of Saturn - taken by a spacecraft that man built and can be remotely controlled with insane resolution and detail (each of those little white-ish specks in the above image is actually a high-res moon, not a piece of dust on the camera lens...).

Maybe its just me, but the whole idea of this fills me with awe and wonder and I feel like a kid again when the universe was huge and the world was a playground full of stuff to learn and explore... and it leads me to just one question:

If we can put men on the moon and send scientific spacecraft to Saturn to take high-resolution photos, then why the $@#(!%)# can we not build a single piece of decent consumer-grade software that isn't slow and riddled with bugs?!

Enjoy the pic! :)

Before I get into the rant proper, let's have a little history lesson. Back in the good old days when developers walked uphill both ways to their cubicle in the freezing snow and hail - there was "classic" ASP. This festering boil on the ass of developers everywhere allowed a big old pile of VBscript to be run inside a file that was also littered with markup. Eventually developers came up with some good practices (like doing everything in a Sub Main, etc) but the end result was still awful spaghetti and it was often very difficult to code multi-state pages because, well, you had to maintain all that state information yourself. Whether your page was in edit mode, confirmation mode, or edit + rainbow + candle mode - all stuff you had to code by hand.

So along comes ASP.NET. The people at Microsoft saw the developer difficulty in using ASP and thought, "We should make the web development experience feel like the windows development experience, with double-click-to-create event handlers!"

Nooooooooooooooooooooo! For the love of all that is good and geeky, Noooooooooooo! Web development should feel like web development dammit!! Web development can feel like web development and still be fun and elegant and easy!!

So.. to give developers the feeling that they're working in a windows world, even though they're on the web, the ASP.NET folks created ViewState. To imagine what this was like, picture one of those mad scientist laboratories where they're working on creating some kind of godzilla-mothra hybrid..they jam 1billion volts into it and it wakes up and spontaneously gives birth to a baby alien-monster... that's ViewState.

You can see a dramatic re-enactment of the birth of ViewState below. You can see the baby ViewState has escaped the host's stomach and is attempting to bring forth an era of dark evil the likes of which mankind has never before experienced....

While their heart was in the right place, the implementation is just downright nasty. The web is not a windows development platform and the simple act of forcing developers to think about their web pages in terms of events and postbacks created a fundamental break between what's really happening on that page and what the developer's are dealing with. This eventually led to the abuse of ViewState, where everything shows up in that damn state bag. I've looked at the inside of some pretty retchid ViewState and I've been appalled by what I've seen. I'm positive that most developers have no clue what's inside the ViewState their page is generating. Many of them assume that because ViewState is a Microsoft invention, it's efficient and can't be abused.

I've seen pages become anywhere from 300KB to 300MB (that's right, MB!) because of ViewState bloat. This creates a burden on both the server and the client: the client has to hold onto that bag and re-transmit it every time and the server has to de-serialize that insanity at the start of every request.

I'm sure there will be people who comment on this blog that ViewState is good if used by properly disciplined people. Sure, that's true, I've done it myself - if you spend a ridiculous amount of time optimizing the use of ViewState by your pages, you can trim it down so you're probably only adding 20-30KB of extra text to the rendered output. My advice, of course, is to simply not bother.

There are two avenues to take here:

1. Use ASP.NET MVC instead. Finally you can go back to programming like a web programmer and ditch the stupid ViewState/Event/Postback goo.
2. Turn off ViewState. Turn it off system-wide and disable it on every page and user control. Then refactor your entire application to survive without it. Or, if this sounds like too much trouble, see #1 :)

Yes folks, this is a rant so I've deliberately exaggerated some of my opinions. For example, I do not believe that ViewState was birthed by an alien-monster hybrid in a lab. Come on, that's totally unrealistic. I do, however, believe that ViewState is the froo-it of the dev-il. That's for realz.

Also, bonus points if you can name the movie from which the "froo-it of the dev-il" reference originates :)

I didn't know it at the time, of course, but I had (and still have) ADD. I do not have any hyperactivity problems and in fact have sometimes been referred to as a sloth in the past. On subjects that I could obsess over and that interested me, I did exceptionally well (except for testing) and on boring subjects I did exceptionally bad (including testing).

A common thread here is testing. I have never tested well and never will. I hate the experience of being in a test. My stomach churns and I fidget, twitch, itch, and otherwise cannot focus on the test. I fail tests for easy and hard classes alike and only in recent adult years have I ever been able to pass a test on a boring topic (passed the MCSD exam for SQL Server 2005.. good lord that test was boring.. I had to take it twice to pass).

While in the middle of a test, there is a single thread running through my mind... it sounds like this "I want to be done. I don't care if I get all the answers wrong I don't care if it ruins the rest of my life I don't care I don't care I want to be done!!!". I remember a mid-term exam for Calculus once while at University - I was maintaining a decent Bish/Cish average. I got to the mid-term, panicked, and randomly picked all answers on the test and fled the mid-term 15 minutes after the exam began. I failed it and tanked my average.

When someone with my particular type of ADD is confronted with a long-running task that gives them anxiety such as studying for an exam, I have two standard responses:

1. Obsess about the studying for, preparation for, and acing of, said exam to the exclusion of all else, including daily responsibilities such as acknowledging the presence of one's family and friends.
2. Ignore it. Avoid it. Run like hell and pretend the exam doesn't exist. When it comes time to take the test, pick random answers and be done with it as soon as humanly possible.

Unfortunately, I have in the past done both #1 and #2. I've spent months preparing for an exam and then blew it off out of raw, primal fear when it came time to take the test. That allows me to wallow in self-pity for months after receiving my 0% grade, further increasing my test-related anxiety.

Want to hear how the cycle of self-destruction continued? I decided to start learning Japanese a while back. I felt as though the study of it was floundering (though I was having a crapload of fun) so I decided maybe if I set a goal, some kind of target, then I'd have more productive studies. What did I set as my goal? Why, the JLPT3 Japanese Language Proficiency Test, a once-a-year, international certification. So I did my usual - I turned what was once a fun passtime/hobby into a hyper-obsessed anxiety-ridden downward spiral while preparing for this test.

So I've decided to not take the test.. ever. Regardless of whether or not I think I can pass it, I've decided not to take it. Within minutes of making this decision, I felt happier, lighter, and less stressed. The ominous, looming shadow of the upcoming test went away and learning Japanese became instantly fun again.

So what's the moral of the story? I'm not really sure. A wise friend of mine once passed a quote (perhaps paraphrased) on to me that everyone should live by:

"Find out what you don't like doing, and stop doing it."

Simple, yet powerful.

My issue here isn't so much with Google Translate as it is with the public perception of Google. I've read a few reviews of Google Translate and seen some blog posts. The general consensus is that because Google built it, its awesome and flawless. People think that Google is building this massive, soon-to-become-self-aware giant brain in the cloud that is sucking intelligence out of search patterns to be used for some world dominating purpose in the future. This is rubbish because we know Google doesn't start Judgement Day, Cyberdyne does. Sheesh, anybody knows that.

So, what's different about Google Translate than other previous attempts at machine translation? The biggest is that Google is using collective intelligence like it uses on its search engine to cull human-supplied translation bits and add those to its existing translation rules. The theory is that it makes for a better engine and should make the translations more in line with what a human would expect.

So how does it fare? You tell me:

My Input	Google's Output	Actual Meaning
内閣は倒れるだろうということだ	Cabinet and they will fall	They say that the cabinet (govt) will fall
その先生は病人だということが分かった	The teacher found that it's sick	The teacher turned out to be sick
私達は彼の死を悲しんだ	We mourned the death of his	We mourned his death
彼の殺人の動機は何だ	What's his motive for murder	What's his motive for murder?

So this is actually pretty enlightening. I have to admit that I was really skeptical when I tried it out. Just like every other machine sentence translator on the planet, if you attempt to use a Google translation to glean meaning from a web page or from a paragraph or even a single sentence, you're probably screwed. The first three sentences I have in the chart show that while verbs and nouns are translated properly, you actually lose a lot of meaning and context in translation. For example, the second sentence - relying on the Google translation I don't know if the teacher is sick or something else - but it's pretty damn close to accurate. The second to last sentence is almost spot on and finally, the last sentence is a perfect translation.

So the verdict is this: the current state of machine language translation sucks and will continue to suck for some time. However, I now know that if I want to get a rough stab at a translation of something I am going to try Google Translate first. Among all the other engines I could find, Google's was far and away the best.

For example, when I plug in the Japanese for "what's his motive for murder?" Babelfish spits out the following: Motive of at that homicide is what.

Someday this won't matter and we'll all have universal translators in our ears. It also doesn't matter much because, as Hollywood has shown us time and time again, all aliens from far and distant worlds speak English.

On a really high level, he's got a valid point : With Azure you can develop your application offline locally and then when you're done you can publish it to a remote host. To the casual observer, this looks exactly like what you might do with a web hosting company that provides space on an IIS box and let's you use ASP.NET and maybe even a little SQL server database.

The beauty, of course, is that to the end user it doesn't matter. To someone using your website, they don't (and shouldn't) care whether your website is being hosted in Windows Azure or a traditional web hosting server environment. The real difference is the underlying plumbing.

In a traditional web hosting environment, the company to whom you're paying your monthly fees has a bunch of Windows Server boxes (virtual or otherwise). Each of these has IIS on it and the .NET Framework. When you rent a website space from them, they create a virtual directory/IIS application (possibly even an App pool if they're nice) for you. So, on their system your application might be at server203/customer909312093 and they very nicely provide a DNS mapping so that www.yourapp.com points to that location on their system and the end users never know about how this plumbing works. The key architectural points to consider here at that there is a single point where your application resides - 1 IIS server, 1 app pool, 1 application/virtual directory within that pool. There is a single SQL server instance, also hosted in a single physical location, and a single database within that SQL server instance that contains your stuff. It is a classic example of the client/server model, with the server parts being hosted by the web host company and the client parts being browsers and other web consumers.

Cloud computing is different. By its very nature it is distributed. When you develop a web application in Windows Azure, there is a chance that there might be 10 different instances of your application running in 10 different data centers throughout the world. This application could be pulling data from partitioned storage in 5 different data centers throughout the world. There can be 5 different instances of the "engine" (a worker role; C# class) running in 5 different data centers, all working on processing the information that your application is taking in and spitting out. Writing a scalable, robust, reliable application in Azure involves being mindful of the architecture of "the cloud", but you don't need to worry about things like how to implement hot failover. You don't have to worry about things like what happens when your web-hosted site gets crushed under the "Digg" effect or "Slashdotted" - if that happens on Azure you just go to the admin site and bump up the number of running instances of your web role and maybe your worker role (you can scale them differently).

Azure is a game-changer. It completely changes the way people think about building scalable and reliable web applications available on the Internet. In addition, other Azure services like the .NET Service Bus allow websites sitting "in the cloud" to securely and reliably communicate with servers sitting inside your corporate infrastructure without opening firewall ports or causing security problems. This allows scenarios like you being able to build an e-Commerce website that sits in the cloud and it can communicate new orders directly to your internal fullfillment system without requiring you to create a gap in your security. The list of scenarios is endless.

The bottom line here when thinking about web hosting vs. Azure is this: Do you want to put up some HTML that might have a limited amount of interactivity or are you trying to publish an actual application? If you want to build an application in the cloud then Azure is your tool... it's not a tool, it truly is an Operating System - an Operating System and SDK for building cloud applications.

Obviously I will be posting more details about Azure, cloud computing, and code samples :) Some of what I've got planned is still under wraps and I can't spill the beans just yet.

• What we know as the Live Framework, that many of us have been developing with for nearly a year (bits released PDC 2008) will be disabled/deactivated/removed as of September 8th, 2009 (6 days from today)
• The end user experience for Live Mesh will remain untouched. In other words, people who have been using Live Mesh as a distributed file share system will be able to continue doing so. Pavan and I wrote a book sharing our chapters using Live Mesh so this is a good thing.
• The ability for developers to create Silverlight Mesh-Enabled Web Applications will be disabled. 
• If you have any data in a developer Live Framework mesh, you'd better get it out of there now because it will be removed.
• You should remove all your devices from developer meshes.

When I first read this, I was all "OMFGWTFNoMesh!?!" and exploded in front of my computer. After cleaning the bits of my exploded brain off the keyboard and looking at it again, some of it made sense. They are taking the Live Framework stuff down and theoretically coming up with a better, more in-depth, more unified API for Live. This step is long overdue because for a very, very long time developers have been confused because there is "old live framework" and then "live mesh/live framework" and then there's Azure and then there's a bunch of crap that's been labelled as part of "Live" for which there is no developer API.

What I expect to happen is that when they come back after hiatus, the Live developer experience will be a far more unified, robust, and more importantly, clear-and-concise experience. Unfortunately, all of us who have spent a truckload of time building MEWA prototypes are boned.

That said, if we eventually regain the ability to access/create/manipulate meshes from inside a Silverlight application, we can easily host a mesh-enabled web application in Azure. This doesn't change the fact that I'm pissed about the fact that MEWAs have suddenly become a dead-end for development and I have no idea if I will ever be able to develop an application that synchronizes across all Live Framework devices written in Silverlight again.

BOO.

• A clean host, this is what I do my day-to-day stuff on : writing, browsing, e-mail, gaming
• virtual machines all over the damn place: every beta, CTP, limited new ultra-shiny thing gets put in a VM and played with until my eyes bleed.

This is normally an adequate situation for me. However, with some things I just don't want the virtualization overhead or the difference in environment. For example, VS2010's GUI is written in WPF and that particular GUI hates being virtualized. When put under a virtual machine running Windows 7, VS2010 fails to render things, borders disappear, windows become unusable and the experience is downright awful. On the other hand, when you run VS2010 "bare metal" with no virtualization between it and your video card, everything is beautiful and all works well.

When reading the blog posts about the VHD boot feature, I realized that I could have my cake and eat it too. I could have the sandboxing, isolation, and easy throw-away that I typically require for evaluating betas and CTPS...but I could also run the sandbox un-virtualized and only incur a 3-4% performance penalty on disk I/O by running inside a single file rather than running in a directory or partition. I can handle that.

So now I've got a VHD on my laptop that boots into Windows 7 Ultimate with a full install of VS2010 and SQL Server 2008 that I can use as a sandbox for building next-gen applications. I've also got a Win2k8 R2 sandbox that is waiting for Biztalk 2009 and/or whatever other server product I want to evaluate. And if I want I can have another sandbox for Win7 that has other CTPs and betas that don't exactly play nice with the current revision of Visual Studio 2010. The only real penalty I have is waiting for a reboot...which is fast on my laptop and painfully slow on my tower.

So.. if you like the isolation, sandboxing, safety, and easy throw-away features you get from virtualization but you don't need to actually have multiple sandboxes running at any given time, then I think using the Boot to VHD option is quite possibly the best developer feature I've ever seen in an Operating System to date.

Anyway, I've got more good stuff to come, I've been spending a crazy amount of time writing Azure apps on ASP.NET MVC and I'm about to start dumping all kinds of goodness on the blog (assuming anybody actually reads this thing anymore).

So go forth, make your VHD files, share them among your friends and co-workers, and enjoy the awesomeness that is Windows 7.

• On-Demand : Something in your application happens and it needs data. It specifically asks the server for that data upon encountering the need for that data. This is what most people think of as "pull" data.
• Push : This is where you need data sent to your application as the data becomes available and the overhead of setting up a timer on which you pull (or poll) for data is unacceptable to you. The main reason why this is unacceptable to people is because there may be frequent periods of time where the pull/poll has no data, which means your app will be occupying server resources every X seconds even when there is nothing to do.

The Polling Duplex channel is a solution to the push problem. It allows server-side code to "push" data down to the Silverlight application. Under the hood the channel is using "Comet"-style tricks keeping HTTP connections open in much the same way that the Gmail application is able to receive push notifications of new mail.

This is great and the programming model for communicating with the Polling Duplex channel is brain-dead simple. It does NOT get any easier to implement push data to a RIA - not in Flash, not in AIR, and certainly not in JavaFX. The problem is that this solution doesn't scale. On the server side, for each concurrently running Silverlight application (so probably one per concurrent user), there is a full live socket being consumed that will not be relinquished until the client disconnects/closes their browser.

Worse is that the Polling Duplex channel defaults to only allowing 10 concurrent connections. You can programmatically tweak that by configuring the throttling behavior (as shown in this blog post here ).Even if you do increase the amount of concurrent connections allowed, those concurrent connections are still going to beat the crap out of your servers and good luck getting that to work seamlessly in a cluster/farm scenario.

If you need more than a handful of concurrent users and you want to do it in a way that scales and doesn't abuse your servers, then I highly, highly recommend looking into some kind of messaging / open gateway server. The only one I've played with for more than a few minutes is Kaazing , but I have nothing but good things to say about it. It's based on HTML 5 Web Sockets so you will be in good shape for the future.

Web Sockets are freaking awesome but that's a topic for another post.

Bottom line here is that if you're looking at any of the Polling Duplex samples online like the "stock ticker" sample, don't be fooled. It looks easy, but especially in the financial industry, you need high concurrency, high speed, low latency - and you're not going to get that with the polling duplex channel. If there was one place where I see it fitting is in the creation of intranet applications internal to an organization with a limited number of concurrent users.