Known Issues for Windows Azure Storage Client Library 2.0 for .NET and Windows Runtime

Article
11/01/2012

An updated Know Issues Blog Post can be found by clicking on this link

The client issues detailed in this blog have been resolved in version 2.0.4 or earlier, and you can obtain the latest NuGet Package here .

We recently released the 2.0 version of the Windows Azure Storage Client Library. This is our largest update to our .NET library to date which includes new features, broader platform compatibility, and revisions to address the great feedback you’ve given us over time. For more about this release see here. For information regarding breaking changes see here.

This SDK 2.0 release contains a few known issues that will be addressed in the next release of the libraries and are detailed below.

Known Issues

Service Client Retry Policy does not support null

The Cloud[Blob|Queue|Table]Client.RetryPolicy does not support null, if you wish to disable retries simply use RetryPolicies.NoRetry (client.RetryPolicy = new NoRetry()).

CloudStorageAccount.Parse cannot parse DevelopmentStorageAccount strings if a proxy is not specified.

CloudStorageAccount.Parse() and TryParse() do not support DevelopmentStorageAccount strings if a proxy is not specified. CloudStorageAccount.DevelopmentStorageAccount.ToString() will serialize to the string: “UseDevelopmentStorage=true” which illustrate this particular issue. Passing this string into CloudStorageAccount.Parse() or TryParse () will throw a KeyNotFoundException.

The example below illustrates this issue:

 // Will serialize to "UseDevelopmentStorage=true"
CloudStorageAccount myAccount = CloudStorageAccount.DevelopmentStorageAccount;
CloudStorageAccount.Parse(myAccount.ToString());  // Will Throw KeyNotFoundException

To work around this issue you may specify a proxy Uri as below:

 // Will serialize to "UseDevelopmentStorage=true;DevelopmentStorageProxyUri=https://ipv4.fiddler"
CloudStorageAccount myAccount = CloudStorageAccount.GetDevelopmentStorageAccount(new Uri("https://ipv4.fiddler"));
CloudStorageAccount.Parse(myAccount.ToString());

Summary

We continue to work hard on delivering a first class development experience for the .Net community to work with Windows Azure Storage. We will address these issues in upcoming releases of the SDK and on GitHub.

Joe Giardino

Windows Azure Storage

Resources

Get the Windows Azure SDK for .Net

Comments

Anonymous
November 01, 2012
"CloudStorageAccount.GetDevelopmentStorageAccount" is marked as internal, so unless we're working from a download of the source rather than the NuGet package, this approach isn't going to work. Hope you're planning to push changes to the Nuget package quickly and not just stash them in GitHub.
Anonymous
November 02, 2012
@Chris - CloudStorageAccount.DevelopmentStorageAccount is public and accessible right? We are planning to fix the parse related bug and update the nugget.
Anonymous
November 05, 2012
The comment has been removed
Anonymous
November 05, 2012
Actually this is also true of the DynamicTableEntity(string, string) constructor.
Anonymous
November 06, 2012
The comment has been removed
Anonymous
November 06, 2012
CloudStorageAccount.GetDevelopmentStorageAccount(new Uri("http://ipv4.fiddler")); This method is not available. There is a property called CloudStorageAccount.DevelopmentStorageAccount but since it is a non-indexing property it doesn't take a parameter. What other - working - work-around do you suggest?
Anonymous
November 07, 2012
@ Chris - You are correct, the code above was taken from our test suite which has access to the internals, we will correct this blog post. The accessible work around is to use the connection string in the format of : "UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler" Additionally, The fix for this has already been pushed to the dev repo in github, and has been published to master : github.com/.../123 And will be live on nuget shortly, Sorry for the confusion. Joe
Anonymous
November 07, 2012
2.0 does not seem to work with Diagnostics dll 1.8; diag 1.8 refs the old library.
Anonymous
November 08, 2012
@ Porges This issue has been reported, the fix is in testing / signing currently. We expect it will be live on nuget / github by mid next week. @Matt, @ victor Unfortunately the current Diagnostics still has a dependency on 1.7( this dependency will be updated in the future). The current workaround is to reference both 1.7 and 2.0 in your project. This is part of the reason behind the assembly name being changed to .Storage.dll rather than StorageClient.
Anonymous
November 10, 2012
I encountered the following issue since upgrading: When I use numeric nullable properties in TableEntities (int?, long?), the insertion part works as expected, but when I retrieve entities, those fields all have null values instead of the value present in table storage.
Anonymous
November 12, 2012
Hi, I've found another issue in the SDK 1.8. The ClouldDrive (from Microsoft.WindowsAzure.CloudDrive) isn't compliant with the last sdk, it needs StorageCredentials from the SDK 1.7. It's a real issue because we can't use it right now! Thanks, Yohann
Anonymous
November 12, 2012
@Quentin - yes this is a bug which we will work on getting fixed. Thanks for reporting it and sorry for the inconvenience.
Anonymous
November 12, 2012
@Yohann - clouddrive has not been updated to use the latest version yet and hence it does not support the 2.0 client library (which uses 2012-02-12 REST version). However, you can use both libraries together and continue using the older client lib for use with clouddrive (and diagnostics) but use the newer 2.0 lib for everything else in your app.
Anonymous
November 27, 2012
There seems to be an issue with {Begin,End}ListTablesSegmented as well; EndListTablesSegmented expects a ResultSegment<DynamicTableEntity>, but BeginListTablesSegmented returns a TableQuerySegment<DynamicTableEntity>. As such, using them results in an InvalidCastException: Unable to cast object of type 'Microsoft.WindowsAzure.Storage.Core.Executor.ExecutionState1[Microsoft.WindowsAzure.Storage.Table.TableQuerySegment1[Microsoft.WindowsAzure.Storage.Table.DynamicTableEntity]]' to type 'Microsoft.WindowsAzure.Storage.Core.Executor.ExecutionState1[Microsoft.WindowsAzure.Storage.ResultSegment1[Microsoft.WindowsAzure.Storage.Table.DynamicTableEntity]]'.

Share via