In case you've been hiding under a rock this past week, Microsoft has been showing off WP7 and the development experience for it. I'm going to oversimplify here, but this is the basic idea: You can choose to either develop for the platform in Silverlight or you can use the XNA toolkit normally used for building XBox and PC games in C#. WP7 has all the trimmings including push notifications, rich GUI (hardware accelerated), rich audio, the full power of Silverlight's media control, and it even has Xbox live integration allowing you to unlock achievements by playing games on the phone. Development tool is standard Visual Studio and for the Silverlight model you can use Expression Blend 4 to build you GUI (and there are some fantastic new improvements in Blend 4).

I'm going to talk mostly about the Silverlight experience here since the last time I used XNA it was in beta and XNA has come a long way since then and I couldn't possibly do it justice. Your application is made of up pages (this concept should be familiar to SL3 developers), with each page acting like a specialized SL user control. These pages can have an application bar, which is similar to an iPhone tab bar control. The difference is that when you tap the elipsis ("...") on the WP7 app bar, the app bar expands without you losing context while the iPhone tab bar "more" button transitions you to a fairly bland table view controller. At this point you can do pretty much anything you would normally be able to do in Silverlight, but you also get things like raw access to audio from the microphone, pickers for all native types of data on the phone like contacts, etc and the ability to send e-mails and SMS - all the stuff you'd expect to have.

So, how does it feel to code for this thing and, more importantly, how does it compare to writing iPhone apps? First, let me preface this by saying that I've been writing iPhone apps off and on since before the SDK came out and we had to "fake it" with clever CSS and HTML and for the past few months I've been seriously writing heavy duty iPhone apps for real businesses. On many occasions over the past few months, I've said that developing for the iPhone was 'fun' and 'what coding should be like'. That said, I have also forcibly rammed my head into my desk out of frustration with certain aspects of the iPhone development process.

Writing apps that look and feel like iPhone apps that look just like every other iPhone application is a task that takes little to no effort. I can go from empty project to a data-driven table view controller on the iPhone in pretty much no time at all. I can also do the same thing on the WP7 tools in about the same amount of time. Where the two begin to diverge is when I want to start customizing. I won't go into painful detail here because I plan on making a bunch of blog posts about WP7 and comparing it to the iPhone later. There are a few points that I want to make, however:

Push Notifications

As I said, I plan on delving into individual topics as I blog more about this, but I wanted to bring this up specifically. Dealing with the App Store and with the Developer Portal in general on the iPhone is a headache at best. When you add into it the juggling, management, and eventual botching of certificates and provisioning profiles, the mess gets even worse. Now you add into it the debacle of getting certificates based on provisioning profiles that are used by your servers to send push notifications to registered iPhone devices and it can bring the strongest of men to weeping on his knees. From firsthand experience, the act of getting your first push notification to work on an iPhone/iPod touch application is akin to climbing mount everest and when you get to the top you're thinking, "#@*! I have to do this again!?" With Apple, the phone contacts Apple to get a notification token (assuming the application is using a provisioning profile configured for notifications), the token then has to be sent by the app's code to the app owner's server for storage. That server needs to be configured with the right certificates to that it can send a proprietary binary package of goo containing the notification to Apple's servers, which will eventually make its way down to your app. Trust me, getting this to work is a victorious moment, preceded by weeks of eye-gouging pain.

Here's how it works with WP7: App gets a unique notification URI that represents notifications for that app on that device. App sends the URI to the app owner's server. When you want to send a notification, HTTP POST the contents of that notification (XML payload) to Microsoft's notification server. That's it. Done.

Small side note here: I like that you can send unobtrusive toasts with WP7 far better than sending modal dialog boxes with iPhone, they feel more like the Palm Pre notifications than iPhone dialogs. There are no certificates and private keys to manage, there are no provisioning profiles to deal with, there are no certificates required to be present on the notification sending server and there is no management portal you have to go to in order to maintain this stuff. For the first time recent history, Microsoft took the "it just works" approach whereas Apple's is hideously and unnecessarily complex.

GUI Customization

I alluded to this earlier in the post. If what I want to do is display two rows of textual information in a table view cell, then the iPhone gives me that out of the box and my application will feel perfectly at home on the device. However, when I want to mix in some icons and some other gauges and indicators that might not fall into the existing line-up of controls, I quickly drop from feeling safe and secure to feeling like I'm back in the low-level Windows programming days of yore where everything I do needs to be a custom view with a custom render/paint method. It gets tedious, difficult, and time-consuming FAST.

Because WP7 lets me do all this stuff in Silverlight, I can use the advanced, composited, declarative UI to do truly remarkable things in very little time at all. I could make the cells in my table view (list view or grid in SL) have three rows and put whatever controls I want in there. Creating a type of UI that doesn't exist in the stock toolbox in Silverlight is easy... doing the same in the iPhone feels positively primitive by comparison.

Overall Experience

As you'll see in the blog posts I'm planning on doing, WP7 development is like a  breath of fresh air. It's funny, because I remember saying that when I first got my hands on the iPhone SDK and I was comparing iPhone development to Compact Framework for Windows Mobile. Cast aside all your preconceived notions about all previous versions of Microsoft mobile OS development - this is something entirely new. Also, keep in mind that when you build your mobile app in Silverlight, if you do it with a little forethought, you could potentially share 90+% of your code for an app that works on WP7, on a PC, and on a Mac.

I will still build apps for the iPhone, but only because people continue to want to pay me to do so. From now on, my mobile development for pleasure is going to be entirely WP7 based.

So this is when I decided to write an HTML helper extension, JqGridExtension. This class exposes a single method called JqGrid that you invoke like this from your view page:

<%= Html.JqGrid<ApplicationUser>(
    caption:"Users",
    entityNameCaption:"User",
    gridWidth:700,
    formHeight:500,
    formWidth:600,
    pagerDivName:"pager",
    gridTableName:"userGrid",
    gridDataUrl:Url.Action("GridData", "User"),
    gridEditUrl:Url.Action("SaveUser", "User"),
    gridValidateEditUrl:Url.Action("GridValidateUserEdit", "User"),
    gridValidateDeleteUrl:Url.Action("GridValidateUserDelete", "User"))
%> 

In this code example, you can see that I'm creating a full CRUD grid with form editing (and paging, sorting, and filtering!). The cool part here is that I haven't littered my page with 100+ lines of incredibly difficult to read parameters to the jqGrid plugin. The HTML extension is just a method on a static class that returns a string, like this:

public static class JqGridExtensions
{
public static string JqGrid<T>(this HtmlHelper helper,
    string caption,
    string entityNameCaption,
    int gridWidth,
    int formHeight,
    int formWidth,
    string pagerDivName,
    string gridTableName,
    string gridDataUrl,
    string gridEditUrl,
    string gridValidateEditUrl,
    string gridValidateDeleteUrl) { .... }

The code then just uses these parameters to spit out all of the tedious jqGrid code that I don't want to have to re-write all the time. There's another little piece of trickery here that I found extremely useful - I'm using a custom attribute that I'm decorating my viewmodel properties with. This custom attribute tells my jqgrid extension how it should handle that column - including whether the column is visible in the grid, visible in the form, editable, what the editor type is (text, datepicker, etc).

All I'm really doing is getting the list of public instance properties on typeof(T). For each of those, I grab my custom attribute (JqGridColModelAttribute) and use the properties on that to build the "colModel" and "columns" jqGrid options and then finally I rig up the navigator and all the other stuff. Because the enterprise's use of grids is standardized to always have a certain set of options, I don't need to even prompt the developer for those - I just implement them the same way throughout the organization. If I need to make organization-wide changes to all of my grids, then I can just tweak my HTML helper method.

Creating an HTML helper extension like this takes very little time to do, but saves the developers on your team a TON of time.

I've known quite a few developers who tried their hand at programming for the iPhone and they threw up their hands and quit when they started trying to track down memory problems. I'm certainly not condoning that kind of behavior, I'm just recognizing that the lack of built-in garbage collection represents both a learning curve and a frustration obstacle for new iPhone developers, whether they've been doing other programming for 2 or 20 years.

Thankfully, there's something you can do about it. One of the biggest problems people get is an EXC_BAD_ACCESS error that terminates their debug session, but the callstack is empty and it's nearly impossible to figure out which method call caused the problem. There are several causes for EXC_BAD_ACCESS but the #1 most common cause for this is the attempt to send a message to a released object. The problem arises from the fact that since the released object isn't there, the bad access occurs and the call stack goes away before the debugger stops.

This is where NSZombie comes in. NSZombie is quite possibly one of the coolest, most clever tricks I've ever seen in a programming environment. The way it works is, when you have zombies enabled (will show you how to do this in a second), a released object becomes a zombie when released. What this really means is that instead of deallocating and moving on, the original object is deallocated and an instance of NSZombie is left in its place. The sole purpose of NSZombie is to yell at you whenever someone tries to send it a message. Any message sent to a zombie will halt the debugger and put an entry in your console log telling you that you just tried to send a message to a released object.

I cannot even begin to describe how useful this is. This preserves the call stack so that you can see the exact line of code that sent a message to the released object. While this won't necessarily tell you what you did to prematurely release the object (premature release... too funny), it will tell you which object was released and what message you were trying to send and it'll preserve the call stack to give you other valuable debugging information.

To enable NSZombies all you need to do is double-click the application file in your "Executables" group and go to the parameters tab. At the bottom you'll see an area to configure environment variables. Add an environment variable called NSZombieEnabled and set its value to YES. Your screen should look like the screenshot below: 

Now that zombies are enabled, you will be able to run your application and know that when you send a message to a released object, you're going to get a nice friendly execution termination, complete with call stack. You'll know which message was sent and you'll know which objects have been released because when you hover over them after the break, you'll see which ones are concrete instances (still alive) and which ones have been released (they'll be an instance of NSZombie).

Moral of the story: Not only are the undead good for entertainment value and destroying the earth in an unforgiving plague of destruction, but they're handy debugging tools as well.

At one point I was actually thinking about writing a book for .NET developers to learn Cocoa but other plans, time constraints, and life issues all got in the way. I have posted countless times comparing the worlds of Cocoa and .NET and have twice presented at Apple's WWDC comparing both the desktop and mobile programming environments of Apple and Microsoft. So you can imagine the raw, unfiltered, pure geek joy that coursed through my veins when I heard about Monotouch, a programming library coupled with an IDE (MonoDevelop + Interface Builder) that would let me write my iPhone applications using C# and the .NET Framework (the mono version).

To get Monotouch working you're going to need the following:

• A Mac.
  • Intel
  • Running Leopard or Snow Leopard
  • Decently fast (a current Macbook Air is about the slowest I can tolerate for compilations)
• Monotouch Framework (can download the eval free)
• MonoDevelop - IDE for mono and monotouch, for the Mac, NOT Windows or linux!
• $500 for the professional edition, $3500 for the enterprise edition. You can evaluate for free, but you can't put a monotouch app on an actual piece of hardware without forking over the duckets.

Understanding all of the plumbing of how this works requires a time investment that I just can't put forth right now. So, for now, assume that little magic elves within the MonoDevelop IDE perform post-build tasks on your compiled mono application that can then convert it to native iPhone code. When you're working with C# classes like UITableViewController, all you're really doing is telling the post-compile steps that your final C type in the native app will be a UITableViewController. It's smoke and mirrors, but it's damned powerful smoke and mirrors.

So what's it like to build a monotouch application? It's actually pretty similar to building a regular Cocoa Touch application. You create a new project in monotouch (there are several really good "hello world" tutorials available on monotouch from their site). Drag UI elements into your XIB using Interface Builder and, here's where some of the magic starts, create outlets and actions and link your C# code to your interface builder UI elements. I am pretty sure portions of my brain liquified when I first created a C# view controller and ctrl-dragged to link UI actions to the controller.

This is where many of my avid .NET readers are going to think I've simply flipped and gone off the reservation...

Despite the fact that I can now quickly and easily create C#/.NET classes and use them to power my iPhone applications, which gives me access to things like WCF and the absolutely, definitively better XML libraries of .NET... I am not going to be using monotouch for real application development.

ok, I'll pause here to let you all stop shouting, "OMFGWTFTRAITOR!!!1"

A little history: I learned C# in 2000 on .NET 1.0. I published my first book on the .NET Framework in 2001 and have been writing blogs, books, articles, and flaming truckloads of code on this framework for the past 9 years now. If there ever was a human being on the planet who should by all rights reach out to and lovingly hug the Monotouch box - it should be me. However, all of that time and experience has made me wary of layers of abstraction. I learned how to write Cocoa for the Mac when Leopard was in beta. I found the learning curve steep, and painful. I felt like I was being deprogrammed - but it was a good thing. If you remember my blog posts from that era, you'll recall that I felt like I was growing as a programmer and architect. My skills in .NET increased dramatically as a result of the enlightenment that I found while learning Cocoa and Objective-C. My .NET skills also increased (though not as dramatically) when I suffered through writing enterprise Java applications.

I literally spent hours trying to write down the list of reasons why I didn't want to use Monotouch and some of them were extremely valid reasons concerning the fact that monotouch is always going to be behind the leading SDK revision from Apple and blah blah yadda yadda... The bottom line is I just love the way it feels to write Objective-C and Cocoa code. Period.

Bottom line:

[self heart:Cocoa];

That said, there are a thousand reasons for people to use monotouch, including the ability to re-use .NET (mono) code across the client (iPhone) and server as well as to allow .NET developers who have absolutely no experience with Cocoa or Objective-C to quickly and easily get rolling building iPhone apps. In the real world we don't always have the luxury of learning new languages and environments - if you're a .NET developer and your boss tells you write an iPhone app for your company and to do it in 3 weeks or you're fired - you're going to use Monotouch (and so would I). I have the luxury of knowing both .NET and Cocoa and so I can pick and choose. Knowing both, I'll be writing my iPhone apps in Cocoa and the back-end servers that support them in .NET.

First of all, if you're using Visual Studio 2010 Beta 2, then you're going to need to either up-convert the AspProviders project. For this, you want to go and grab the AspProviders (VS2008) sample from the Azure Code Samples home page. Once you've got it, you can either compile it in Visual Studio 2008 or, if you're coding in VS2010 Beta 2, you can either reference the compiled binary directly or just up-convert the project to VS2010 Beta 2.

The new AspProviders sample uses the new Microsoft.WindowsAzure.StorageClient library that now comes with the new version of the SDK. This version of the storage client is more robust, better supported, and more efficient than the sample storage client from previous versions of the SDK.

First, you're going to want to rig up your Web.config to use the new provider with elements like this:

<membership defaultProvider="TableStorageMembershipProvider" 
userIsOnlineTimeWindow = "20">
      <providers>
        <clear/>

        <add name="TableStorageMembershipProvider"
             type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageMembershipProvider"
             description="Membership provider using table storage"
             applicationName="AspProvidersDemo"
             enablePasswordRetrieval="false"
             enablePasswordReset="true"
             requiresQuestionAndAnswer="false"
             minRequiredPasswordLength="1"
             minRequiredNonalphanumericCharacters="0"
             requiresUniqueEmail="true"
             passwordFormat="Hashed"
                />

      </providers>
    </membership>

    <roleManager enabled="true" defaultProvider="TableStorageRoleProvider" 
cacheRolesInCookie="true" cookieName=".ASPXROLES" cookieTimeout="30"
                 cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration = "true"
                 cookieProtection="All" >
      <providers>
        <clear/>
        <add name="TableStorageRoleProvider"
             type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageRoleProvider"
             description="Role provider using table storage"
             applicationName="AspProvidersDemo"
                />
      </providers>
    </roleManager>

    <!--<profile enabled="true" defaultProvider="TableStorageProfileProvider"
 inherits="UserProfile">
      <providers>
        <clear/>
        <add name="TableStorageProfileProvider"
             type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageProfileProvider"
             description="Profile provider using structured storage"
             applicationName="AspProvidersDemo"
                />
      </providers>
      --><!--   
            <properties>
                <add name="Country" type="string"/>
                <add name="Gender" type="string"/>
                <add name="Age" type="Int32"/>
            </properties>
            --><!--
    </profile>-->

    <sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">
      <providers>
        <clear />
        <add name="TableStorageSessionStateProvider"
             type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider"
             applicationName="AspProvidersDemo"
             />
      </providers>
    </sessionState>

You might have noticed that I've commented out the profile provider. This is because if you use the profile provider, you might run into a problem where an exception is thrown at runtime (during app startup) that complains about you attempting to access an unloaded AppDomain. Microsoft is aware of this and I'm expecting to shortly see a workaround, fix, or an update to the SDK. In the meantime, just comment out the profile provider and you'll be able to use the provider samples as-is.

Keep checking back here for more blog posts on using the new Nov 09 CTP of Windows Azure and any potential updates/fixes to this particular issue with the profile provider.

Table storage, under the hood, is exposed as an ADO.NET Data Service (formerly Astoria). As a result, if you've used the System.Data.Services.Client library before, you've already got a leg up in interacting with Azure Storage.

When you're working with table storage, there are a few things that you're going to need. Once you've got these, you're good to go:

• References to System.Data.Services.Client and Microsoft.WindowsAzure.StorageClient (obviously you also need a reference to service runtime if you're hitting table storage from within the cloud itself... remember that you can hit table storage from the desktop too, e.g. from WPF applications).
• Credentials. There have been some changes to the way storage client credentials work that are beyond the scope of this post, but you can still use the same accountname/account shared key pattern that you used in the past.
• A DataServiceContext. You're going to need this to interact with the tables in table storage. As you'll see in the code below, the pattern is to create your own context that derives from the base and exposes your tables as IQueryables. If you've ever worked with ADO.NET Data Services or Entity Framework before, this pattern should also look familiar.
• Entity objects. Every table that you have in table storage contains arbitrary columns. In other words, if you really wanted, you could have a different schema for every row in your table. However, to work with it using the Data Services client, each row needs to conform to a fixed schema - this fixed schema you'll represent with a regular C# class that contains the necessary partition key and row key properties. This class also needs a parameterless constructor (required by the data services client to reconstitute instances of that class from the HTTP results)
• The cloud table client. This new class will let you create tables and test for the existence of tables. You do not need to use this class for querying table storage, it's more of an administrative class for dealing with table storage itself.   

The first thing we're going to want to do is get the credentials. The new SDK allows us to dynamically determine if we're running in a fabric or running as a standalone app (which allows us to build apps that we can run on-premise OR in the cloud!). Here's some code I used to get the configuration settings for the account name and shared key:

Once you've got the account key and the account name, you can get an instance of the storage credentials and table client classes:

Using the table storage class, we can create a new table (if it doesn't already exist):

Here I'm also using my customer context class and my customer row class (will show those shortly) in order to put a new customer into table storage. Note my use of an application name for the partition key and the username for the row key. Entire chapters of books can (and will) be written on strategies and patterns for using partition and row keys.

Now let's say that we're inside an MVC 2 controller and we want to make the list of customers available to the view. If we're not doing a strongly typed view (which we should be doing unless we can't help it...) then we can use code that looks like this:

Now let's look at the CustomerContext class:

The CustomerRow class is just a POCO class that has a default constructor and a constructor that takes a partition key and a row key, and inherits from the TableServiceEntity class.

I snipped out the rest of the class for brevity - I'm assuming we've all seen stock property accessors before. At this point you should be ready to roll using table storage. There is also one other benefit they gave us in November 2009 CTP - you no longer need to pre-rig your database schema in your SQL 2008 database!! The new development storage simulator accurately simulates the dynamic schema nature of the actual table storage in the cloud. I can't begin to describe how many headaches this alleviates.

Enjoy table storage on the new Nov 2009 CTP and I'll be posting similar blog posts about the new Queue storage and Blob storage clients shortly!

First, install the Windows Azure SDK and the Windows Azure Tools for Visual Studio, making sure you pay attention to all of the installation details. There are lots of little hotfixes and things that you might need. Luckily, if you're running VS2010 Beta 2 on Windows 7, you have very little extra work to do beyond configuring IIS 7 for WCF HTTP activation.

Once you've got that installed, create a new project. The project template you're looking for is in the group Cloud Service and is called Cloud Service. Once you give this new solution a name and click next, you'll be given a dialog box that looks like the one in the screenshot below:

The fantastic thing here is that you'll see, without us having to do any hackery or modify any .csproj files with notepad, there is a web role available for an ASP.NET MVC 2 application. Click the right-arrow button to add that to your cloud service and then pick a worker role if you want one.

After you get that started, if you are running SQL Express, you should be able to hit F5 and see a nice hello world application. The local development storage simulator requires either SQL Express or a full version of SQL 2005+. If you're not running SQL Express and you're running a full version of SQL 2008 like a real developer (kidding!) then you'll need to open up a command prompt. Go to the c:\program files\windows azure SDK\v1.0\bin\devstore directory (this is the same for both 64 and 32-bit systems). Then run the following command:

dsinit /sqlinstance:. /forceCreate

If you're not using the default SQL instance, then replace the "." with the name of your instance. If your windows account doesn't have sufficient permissions to do this, then you'll need to either rectify that using SQL Server Management Studio or use an optional command-line parameter to specify the SQL server credentials required to create the development storage schemas. After executing this command, you'll see a dialog box like the one below:

Now you should be good to go. If you hit F5 in Visual Studio 2010, you'll see some scrolling messages in the status bar about "waiting for roles to startup" and it'll take a few minutes initially, but eventually you'll see the default home page from your MVC 2 project. If you think you're done, think again.

Just as with getting the MVC 1 project to work on Windows Azure, you cannot use the default providers. These providers work against a local SQL Express database by default and they don't work against cloud storage. You're going to need to fix this before you deploy your application to the cloud. For that, you're going to have to wait for my next blog post ;) Get your hello world working locally and then you'll be ready to tweak it as you follow along with my next post.

Anyway, if you'd like to get your hands on some WIF action, click here for the download link.

It doesn't appear as though there are a lot of changes in the framework itself, though I think there are some possible breaking namespace changes but, I'm still downloading it so I don't know at this point. Also, you might want to pick up the Identity Training Kit. It has been revised and there's a new installer for the samples that works on Windows 7 that actually works and installs the SSL certs properly. Previous versions of the ID kit required lots of manual futzing around to get things to work properly with UAC and permissions and the whole "Internet Zone" download issue.

Enjoy!

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 :)