Freigeben über


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

 

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]]'.