Windows Azure AppFabric Cache's Miniscule Features

 

Just wanted to warn/inform people who are considering using AppFabric Caching in Azure…

Here’s a list of things it won’t do:

• Regions
• Named Caches
• Allow you to get a list of cache keys currently in use
• High Availability Mode (redundant copies across machines for durability)
• No sliding window expiration
• No events for things like eviction, add/remove, etc.
• so you can’t update a local cache with events from the global cache
• You don’t get notified if something is removed, so you only know when you get “null” back from a Get()
• No Powershell integration (if you’re into that)
• No tag support (tagging is basically used for some extra metadata besides the key without pulling the whole object)

So, basically, ALL you get is a simple, Get/Set distributed cache that doesn’t even support the whole set of features you get from the basic ObjectCache in .NET 4.0

They really shouldn’t be calling it “AppFabric Cache” at all, since it doesn’t really support anything that comes with that API

I must say that I’m really disappointed

We waited a LONG time for this feature and got something that could have been coded in a month.

Bad form, Microsoft.  Bad form!

Conflicts Between Versions Of Assemblies

 

I just upgraded a project from the Azure SDK 1.4 to SDK 1.5.  I started getting the "Found conflicts between different versions of the same dependent assembly" warning on the Microsoft.ServiceBus.dll file.

I thought to myself, "Self, I've seen this before.  You're just referencing the wrong copy of an assembly somewhere"

So, I checked every reference to Microsoft.ServiceBus.dll … Hmm… they're all correct. ??

I did a full rebuild… still there..

I did a super-duper clean (close the project, delete every "bin" and "obj" folder, open the project and rebuild)… nope…

Time to get medieval on this stuff… So, I opened the topmost assembly (in this case, my Web application assembly) in ILSpy. I stared looking through each and every referenced assembly until I found the culprit:

Microsoft's own Transient Fault Handling library (used for retrying database calls in Azure).  Now, I've contacted the team who wrote that, hoping that they will update their NuGet package.  Otherwise, I'll have to add that ugly Binding Redirect in my config file.

For now, I'll just stare at the warning for a while and hope the NuGet package gets a quick update

Useless Properties

[WARNING: hyperbole ahead!]

So, apparently the UserData property on the ASP.NET FormsAuthenticationTicket object is basically useless.

The UserData isn't persisted if you're not using cookies.  So, you get no errors, no warnings, the code runs fine, it just doesn't actually persist that data.

Nice going, Microsoft!

I volunteered for Give Camp in Baltimore

Geeks doing geeky things for charity!

Seems like a good idea.  I haven't done it before, so it should be a novel experience.
I'm one of those people that always wants to be charitable, but never really gets around to it.

Helping to make a functional website for a non-profit organization over a weekend seems like a pretty good way to do it.

Oh, it turns out that my employer is one of the Corporate Sponsors of the event as well!