Getting Started with Azure

Since the Microsoft PDC at the end of October, I've been tasked with digging into Windows Azure to see where it might fit into plans for a project we are working on. I've had to merge this responsibility in with the rest of my daily responsibilities designing and building other applications, so I end up starting and stopping a lot on my research. It's great that my job offers me not only the opportunity to do these things, but the flexibility to even consider using technologies that are barely CTP for projects that we need to deliver within the next year.

I've done a lot of research, but I don't think I've even seen the tip of the iceberg yet on what is involved in designing a real, production application for Azure. There are so many things to consider when jumping to a completely new platform, that it's not just almost overwhelming, at times it IS completely overwhelming.

The best suggestion I could give someone who is just starting out, is to do the Hands On Labs for Azure. In fact, there are all kinds of samples to try. The difficult thing is to try to remember which ones you have done, and which ones you haven't. If I could make one suggestion to Microsoft is that they need to pull all the various SDK's and Toolkits and Samples together into one "Cloud Computing Toolkit Package" that a developer can download once, installs into one location, and provides a unified index for finding what you need quickly. I find it quite embarassing to post what I think is a valid question onto the MSDN forums only to find out that topic was well covered in an SDK Sample I just hadn't found yet. I take a lot of pride in not wasting other people's time in having them do my research for me.

Here's a list of the SDK's / Toolkits and samples available regarding The Microsoft Cloud

Azure Services Kit: Contains the Hands On Labs - Installs to c:\AzureServicesKit by default. Start with this one and go through all the labs. Every case is quite simple, but well done, thought here are a few errors in the code

Windows Azure SDK - Samples are included in a Zip file. On my machine, this installed to C:\Program Files\Windows Azure SDK

Microsoft .NET Services - Samples include AccessControl, Service Bus, Workflow and are installed on my machine to C:\Program Files (x86)\Microsoft .NET Services (Nov 2008 CTP) SDK

Microsoft Sync Framework - C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework

Silverlight - C:\Program Files (x86)\Microsoft SDKs\Silverlight

Microsoft SQL Server Data Services SDK - C:\Program Files (x86)\Microsoft SQL Server Data Services SDK

Windows Live ID - C:\Program Files (x86)\Windows Live ID\WebAuth\Sample

Windows Mobile - C:\Program Files (x86)\Windows Mobile 5.0 SDK R2

I'll add more links as I find them.

Fun with Entity Framework

So despite spending the first 6 months of the year becoming proficient and LINQ to SQL, the realization that Microsoft was casting aside LINQ to SQL in favor of its grumpy old uncle Entity Framework made me take a serious look at the EF for my latest big project. Luckily, it hasn't had too much of a learning curve, but I haven't gotten to the hard stuff yet either. I'll need to pick up a book on it at some point, but I'm still thrashing my way through WPF at this time and don't need another book to read right now.

One thing that frustrated the crap out of us here last week was not being able to go from a child entity to a parent entity easily. That is, until I learned the trick. And there's always a trick, isn't there.

Say you have a collection of warehouses, and each warehouse has a collection of doors. Given a door id (GUID), get the warehouse it is at. The WarehouseID is foreign keyed to the Door table.

You would think (based on LINQ to SQL), that you could go Door.WarehouseID or at the very least Door.Warehouse.WarehouseID... but alas, no can do. EF hides the relationship through an object called an Entity Key. In my brain, this was a little ridiculous, since I knew what my key was, just give it to me.

But I guess this is why I don't design frameworks for a living. The Entity Key is a dictionary collection, of all the keys that make up the relationship. Thus, if you have more than one column in the key, the EntityKEy collection contains both keys, but you can access it to use those values with a little care.

By adding a property to the Door object in a partial class, you can access the dictionary to extract the value. If you have multiple values in your key, be careful to index the Key properly.



public Guid WarehouseID
{
get
{
return new Guid(WarehouseReference.EntityKey.EntityKeyValues[0].Value.ToString());
}
set
{
WarehouseReference.EntityKey = new EntityKey("ContextName.Warehouse", "WarehouseID", value);
}
}


Back from the Great Beyond

Ok, I haven't been dead, I've just been time travelling. No, really. I jumped back in time to work on a big client project in Visual Studio 2005 using the Microsoft CAB and MVC pattern. While I did learn quite a bit about the client's business (which is not a bad thing), it wasn't technically challenging. In fact I slowed down on my reading of technical stuff, spent more of my free time (ok commute time), reading for fun, and writing for fun. Yes, writing can be fun too.

I also spent a lot more of my nights and weekends doing work for the project, which meant less tech reading as well. A lot of the changes I needed to make to the client systems in preparation for the rollout had to be done off hours to minimize impact on the user.

Sure, I learned a few tricks and tips in the last couple of months. I got very familiar with the Infragistics NetAdvantage Product Set, including the UltraWinGrid (very nice) and UltraWinSchedule (a little buggy in the version I had). But for the most part, I've been just churning code, doing database work, and doing rollouts.

That project is just about over now, with final rollout scheduled for this Saturday. My new project is all new technology, and I'm jumping in with both feet. I've spent the last few days watching videos, reading blogs, and running sample code.

What's got my attention, you ask? Windows Azure. Windows .NET Services. Microsoft SQL Data Services. WPF. Silverlight2. LiveMesh. Yep, 4 of those 6 things are still in CTP, and I'm jumping in with both feet. I'm not just going to be on the bleeding edge, I'm fully stabbed in the chest, in a full out ebola like blood letting.

We'll see how I feel about it in a couple of months, but right now, I'm really excited. My night stand reading is piling up with tech books and blogs. I'm not sure how much I'll be able to post, but I'll try to post hints, tips and other cool things to look at as I learn.

By the way, the current book I'm reading is Pro WPF in C# 2008. I'm just a chapter or so into it, but WPF is something I need to know inside and out for this project, so expect a few blogs on that.

Autocomplete Extender Lesson Learned, Part Two

It turns out that the problems with the AutocompleteExtender actually go even deeper than the dispose problem. Or not as deep, depending on how you think about it. At some point in my effort to make my website pretty, the problem of the extender not extending after a partial postback reappeared. After spending a large, large amount of time on this, I found reference to another bug in the AJAXControlToolKit that happens if you programmatically set the focus back to the textbox associated with the extender control after doing a postback (partial or not).

I removed the set focus statement, and I am back in business. Again.

But dude, seriously?

Converting from a Web Project to Web Site

If you've converted from a VS2008 Web Project to a VS2008 Web Site, and tried to bring pages from one over to the other, you may have been stuck with the issue that your code doesn't see the objects created by the aspx. i.e. the text boxes, the drop downs, etc.

After you spend a while trying to match up namespaces, and letting Resharper fix a bunch of issues for you, you may still be stuck.

Here's one thing to check:

In your page directive, check to see that the compile has chnaged the CodeBehind attribute to read CodeFile. That's got me twice now. That's reason enough to blog about it.