Windows Azure Storage API 2.0 (Breaking Changes und Migration Guide)
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
- Windows Azure Release Notes (Oktober 2012)
- What’s New in Storage Client Library for .NET (Version 2.0)
- Introducing Windows Azure Storage Client Library 2.0 for .NET and Windows Runtime
- Windows Azure Storage Client Library 2.0 Breaking Changes & Migration Guide
Comments
Anonymous
November 07, 2012
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 :(Anonymous
November 07, 2012
@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.