Windows Azure Storage API 2.0 (Breaking Changes und Migration Guide)

Windows Azure Storage API 2.0 (Breaking Changes und Migration Guide)

Rate This
  • Comments 2

Mit dem Windows Azure SDK für .NET (Oktober 2012) wurde auch eine neue Client API für den Windows Azure Storage veröffentlicht. Details zu den darin enthaltenen Neuerungen finden sich in einem Blogpost des Windows Azure Storage Teams.

Die Version 2.0 der API enthält allerdings auch einige Breaking Changes, die beachtet werden müssen, wenn ein Umstieg zu Version 2.0 vollzogen werden soll.

Namespaces

Die Namespaces in der Storage Client API wurden grundlegend überarbeitet. Hier ist eine Übersicht über die aktuellen Namespaces:

Namespace Beschreibung
Microsoft.WindowsAzure.Storage Allgemeine Typen wie CloudStorageAccount und StorageException. Die meisten Anwendungen sollten diesen Namespace einbinden.
Microsoft.WindowsAzure.Storage.Auth Das StorageCredential Objekt, das mehrere Formen der Zugriffs kapselt (Account+Key, Shared Access Signature, Anonym)
Microsoft.WindowsAzure.Storage.Auth.Protocol Authentifizierungshandler, die SharedKey und SharedKeyLite für ein manuelles Signieren von Requests unterstützen.
Microsoft.WindowsAzure.Storage.Blob API für den Blob Service.
Microsoft.WindowsAzure.Storage.Blob.Protocol Protokollschicht für den Blob Service.
Microsoft.WindowsAzure.Storage.Queue API für den Queue Service.
Microsoft.WindowsAzure.Storage.Queue.Protocol Protokollschicht für den Queue Service.
Microsoft.WindowsAzure.Storage.Table API für den Table Service.
Microsoft.WindowsAzure.Storage.Table.DataServices Inzwischen veraltete Table Service API (basierend auf System.Data.Services.Client).
Microsoft.WindowsAzure.Storage.Table.Protocol Protokollschicht für den Table Service.
Microsoft.WindowsAzure.Storage.RetryPolicies RetryPolicy-Implementierungen (NoRetry, LinearRetry und Exponential Retry).
Microsoft.WindowsAzure.Storage.Shared.Protocol Analytics-Objekte und die Core-HttpWebRequestFactory.

Breaking Changes

Hier eine stichpunktartige Auflistung der Breaking Changes. Für eine detailliertere Beschreibung siehe den Original Blogpost des Windows Azure Storage Teams.

Allgemeine Änderungen

  • Keine Unterstützung mehr für .NET 3.5. Clients müssen .NET 4.0 oder höher nutzen.
  • Kein Cloud[Blob|Table|Queue]Client.ResponseReceived Event mehr.
  • Alle Klassen sind als sealed deklariert (wegen Unterstützung der Windows RT Library)
  • ResultSegments sind nicht mehr generic.
  • Änderungen in den Retry Policies.
  • Änderungen bei den StorageCredentials.
  • Vereinfachte Exceptions.
  • Vereinfachte Pagination.

Blob Service

  • Spezielle Klassen für Page und Block Blobs.
  • Änderungen bei parallelen Blob-Uploads und Upload-Blockgrößen.
  • Alle Upload- und Download-Methoden sind Stream-basiert.
  • Vereinfachtes MD5-Handling.
  • Für parallelen Download muss zuvor mindestens ein Lesezugriff abgeschlossen sein.
  • Änderungen beim Protokollmechanismus.

Table Service

  • Neue Table Services API Implementierung.
  • Änderungen im DataServices-Namespace.
  • Änderungen beim Protokollmechanismus.

Queue Service

  • Änderungen beim Protokollmechanismus.

Empfehlungen zur Migration

Die detailliertere Beschreibung des Original Blogposts des Windows Azure Storage Teams enthält zu den einzelnen Änderungen bereits Hinweise auf deren Behandlung in eigenen Anwendungen. Darüber hinaus folgende Empfehlungen für Änderungen:

  • Aktualisierung der Namespaces, um die oben beschriebenen Namespaces zu verwenden.
  • Anwendungen, die bislang über CloudBlob auf Blobs zugegriffen haben, müssen nun die speziellen Klassen CloudPageBlob und CloudBlockBlob verwenden.
  • Explizite Konfiguration des gewünschen Parallelisierungslevels beim Blob-Zugriff.
  • Überarbeitung des MD5-Handlings.
  • Nutzung der neuen API für den Table Service .

Weitere Informationen

Leave a Comment
  • Please add 2 and 2 and type the answer here:
  • Post
  • Vielen Dank für die Lesetipps. Bin tatsächlich schon über das Problem mit der Storage API 2.0 gestolpert. Vorschlag für die Zukunft: alte Namespaces noch als "deprecated" in den Libraries lassen und dann in der nächsten Version entfernen. Dann kann man sich auf die Änderung besser vorbereiten. So muss ich jetzt erst mal bei SDK-Version 1.7 bleiben :(

  • @Peter: Ja, das ist ein guter Punkt. Ich hoffe auch, dass das in Zukunft so gehandhabt wird. Mit der Möglichkeit zur Parallelinstallation von SDK1.7 und SDK1.8 wird das Problem aber zumindest ein klein wenig abgemildert bzw. eine Migration erleichtert.

Page 1 of 1 (2 items)