Spinning Up Some Media Magic

I was looking over some old app designs I shelved last year, they needed some support from something like Windows Azure Media Services, but they weren’t baked last year;  maybe the preview was out when I last looked, not sure.  Recently, I’ve been toying with the idea of getting one of these applications stood up using WAMS now that they’re ready.

I used this chain of posts to get a small harness built and get an understanding of what this stuff does and how it works together to create assets, then encode and stream in various formats, or convert the formats.  The sample code is a bit of a fire house, but the post(s) explain what’s going on with each chunk coming out of the fire-hose.

What I wanted to share is related to a post where I was fighting with a few assembly references and how they were mixed up and giving me a rash.  I asked NuGet for the WAMS bits and here’s what installed:

WAMS.Dependencies

I remember using some of the 1.7 assemblies, but not the 5.1 assemblies;  not a huge thing, but if the other project I was working on last week got mingled with this one, there might be some challenges.

The WAMS stuff looks fun, and its something new for me, I’ve not done much of this stuff except for using OS apps to convert media files from one format to another; so the curve may be steep starting out but yesterday I flattened it a bit and have a working harness that’s using my WA dev account.

HTH / oFc

Table Storage Hiccups

So, like most of us, I thought hooking up table storage would be easy.  Turns out, it’s not if like to keep up with the latest and greatest support libraries.

The first hiccup came when I tried to connect to my local storage service (UseDevelopmentStorage=true).  Well, now you need to specify the URI that points to the local storage emulator and like the blog post author states, “it just magically works”

Now that I had the table sitting there, the next hiccup came when I asked my table service context to build the table if it doesn’t exist.  This one was kind of bad, not something I expected.  First I used the Azure SDK library my exception told me I needed, in this case Microsoft.Data.OData (v5.2.0.0).    There’s a newer version of it as well, v.5.4.0.0, that didn’t work either even with an assembly binding redirect.  I installed v5.4 with NuGet and then had to uninstall it manually by clearing out the package.config entries and dropping the references.  Then using the Package Manager Console I installed v.5.0.2.0 instead w/o the binding redirect and it worked.

The last hiccup was getting the entities to insert into the table.  You can find more about CRUD here, and Table Storage CRUD operations here.  A side note on that embedded link, it discusses versions 1.7 and 2.0 – yesterday I was looking at 1.7, not 2.0 so check which form of the page you are looking at before you start coding.

My partition key was missing and the row key and the timestamp properties were null.  I read that the table client took care of this for me, so I used DateTime.UtcNow for a default property, and fixed up my extension method that gen’d my TableEntity for me.  That error came in the form of [ The remote server returned an error: (400) Bad Request ].

Here are the links I eventually found that bailed me out today.  All the code is working and I added a few more guard statements to do some additional state checks before the CRUD bits fire.  Hopefully, the blob storage stuff is ironed out implicitely as well with all of this dependency churn today.

HTH / oFc

Differences between Azure Storage Client Library 1.7 and 2.0

If you decide to use v5.0.2.0 read this.

What Azure allows inside a table entity during CRUD operations

How to use the Table Storage Service