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

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

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=http://ipv4.fiddler"
CloudStorageAccount myAccount = CloudStorageAccount.GetDevelopmentStorageAccount(new Uri("http://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 (14)

  1. Chris Williams says:

    "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.

  2. jaidevh1@hotmail.com says:

    @Chris – CloudStorageAccount.DevelopmentStorageAccount is public and accessible right? We are planning to fix the parse related bug and update the nugget.

  3. Porges says:

    Here's one:

    The DynamicTableEntity constructor with the signature "DynamicTableEntity(string partitionKey, string rowKey, string etag, IDictionary<string, EntityProperty> properties)" is broken.

    It calls the internal constructor "DynamicTableEntity(string partitionKey, string rowKey, DateTime timestamp, string etag, IDictionary<string, EntityProperty> properties)" with DateTime.MinValue as the timestamp parameter, but this parameter is then cast to a DateTimeOffset. The minimum value of a DateTime is invalid as a DateTimeOffset and the constructor throws.

  4. Porges says:

    Actually this is also true of the DynamicTableEntity(string, string) constructor.

  5. Matt says:

    I have upgraded my solution to use Microsoft.WindowsAzure.Storage (the new 2.0 library) via NUGET.

    It seems that the DiagnosticMonitor depends on version 1.7 though – and the solution will not compile – and I get the following error:

    Error 3 The type 'Microsoft.WindowsAzure.CloudStorageAccount' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.WindowsAzure.StorageClient, Version=1.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

    This occurs on this line of code:

    Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

    What is the recommended solution here?  It seems to me that Microsoft.WindowsAzure.Diagnostics needs to release a 2.0 version.

    Thanks,

    Matt

  6. jettgangster@hotmail.com says:

    CloudStorageAccount.GetDevelopmentStorageAccount(new Uri("http://ipv4.fiddler&quot;));

    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?

  7. Joe Giardino says:

    @ 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&quot;

    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

  8. victor says:

    2.0 does not seem to work with Diagnostics dll 1.8; diag 1.8 refs the old library.

  9. Joe Giardino says:

    @ 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.

  10. Quentin Calvez says:

    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.

  11. ricardolino.ch@live.com says:

    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

  12. jaidevh1@hotmail.com says:

    @Quentin – yes this is a bug which we will work on getting fixed. Thanks for reporting it and sorry for the inconvenience.

  13. jaidevh1@hotmail.com says:

    @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.

  14. Porges says:

    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.ExecutionState`1[Microsoft.WindowsAzure.Storage.Table.TableQuerySegment`1[Microsoft.WindowsAzure.Storage.Table.DynamicTableEntity]]' to type

    'Microsoft.WindowsAzure.Storage.Core.Executor.ExecutionState`1[Microsoft.WindowsAzure.Storage.ResultSegment`1[Microsoft.WindowsAzure.Storage.Table.DynamicTableEntity]]'.