The recently released Windows Azure Storage Client Library for .Net includes many new features, expanded platform support, extensibility points, and performance improvements. In developing this version of the library we made some distinct breaks with Storage Client 1.7 and prior in order to support common paradigms across .NET and Windows Runtime applications. Additionally, we have addressed distinct pieces of user feedback from the forums and users we’ve spoken with. We have made great effort to provide a stable platform for clients to develop their applications on and will continue to do so. This blog post serves as a reference point for these changes as well as a migration guide to assist clients in migrating existing applications to the 2.0 release. If you are new to developing applications using the Storage Client in .Net you may want to refer to the overview here to get acquainted with the basic concepts. This blog post will focus on changes and future posts will be introducing the concepts that the Storage Client supports.
The core namespaces of the library have been reworked to provide a more targeted Intellisense experience, as well as more closely align with the programming experience provided by other Windows Azure Services. The root namespace as well as the assembly name itself have been changed from Microsoft.WindowsAzure.StorageClient to Microsoft.WindowsAzure.Storage. Additionally, each service has been broken out into its own sub namespace. For example the blob implementation is located in Microsoft.WindowsAzure.Storage.Blob, and all protocol relevant constructs are in Microsoft.WindowsAzure.Storage.Blob.Protocol. Note: Windows Runtime component will not expose Microsoft.WindowsAzure.Storage.[Blob|Table|Queue].Protocol namespaces as they contain dependencies on .Net specific types and are therefore not projectable.
The following is a detailed listing of client accessible namespaces in the assembly.
… ICancellableAsyncResult result = container.BeginExists(callback, state); token.Register((o) => result.Cancel(), null /* state */); …
ICancellableAsyncResult result = container.BeginExists(callback, state);
token.Register((o) => result.Cancel(), null /* state */);
In addition to the detailed steps above, below is a simple migration guide to help clients begin migrating existing applications.
A legacy application will need to update their “using” to include:
DataServiceContext (the base implementation of the TableServiceContext) is not threadsafe, subsequently it has been considered best practice to avoid concurrent requests against a single context, though not explicitly prevented. The 2.0 release will now protect against simultaneous operations on a given context. Any code that may rely on concurrent requests on the same TableServiceContext should be updated to execute serially, or utilize multiple contexts.
This blog posts serves as a guide to the changes introduced by the 2.0 release of the Windows Azure Storage Client libraries.
We very much appreciate all the feedback we have gotten from customers and through the forums, please keep it coming. Feel free to leave comments below,
Joe Giardino Serdar Ozler Veena Udayabhanu Justin Yu
Windows Azure Storage
Get the Windows Azure SDK for .Net
I'm trying to use the assemblies from a SSIS scripting task. Any referenced assembly must be GACd. Any chance you will release signed assemblies?
Our client library is signed but not GAC'd - so that should allow you to GAC.
The Diagnostics in SDK 1.8 still has a reference to Storage library 1.7, so for all practical purposes need to continue to hold a reference to Storage 1.7 library as well.
Any feedback regarding the CloudDrive library being updated to 2.0?
Has the ListBlobsWithPrefix method in the CloudBlobClient class been deprecated or replaced in this latest version?
CloudBlobClient.ListBlobsWithPrefix has been replaced with CloudBlobClient.ListBlobs
When you say "The default MD5 behavior has been updated to utilize a FIPS compliant implementation" can you provide a reference to what is now being used? Or can you point me to a resource that defines what components of Azure are or are not FIPS 140-2 compliant?
To answer Stephen B:
The storage client libraries were updated to use the native MD5 implementation provided by advapi32.dll which is FIPS compliant, whereas the default implementation available in .Net is not certified.
For more information about Windows Azure Compliance see: www.windowsazure.com/.../compliance