Azure Storage Client 2.0 and nullable values bug RRS feed

  • Question

  • Hi

    I've started using the new 2.0 storage library and noticed that then I retrieve a nullable value from a table (eg int?) then a null is always returned as the value, even if there is a value in the table.

    I've changed some properties to their non-nullable counterpart and tested again, this time the correct value is returned.

    This seems to be a bug in the client library. Is there a workaround to this or a new version that fixes this issue? If so, how or when? We've been through the excerise of migrating our code, but we can't deploy because of this bug!

    There is mention of this problem in the comments section of this page: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx


    Wednesday, November 14, 2012 7:20 PM


All replies

  • Hi David, according to the second comment from Gabriel Michaud, seems he resolved it. Have you check his hint?
    Thursday, November 15, 2012 3:17 AM
  • Hi _mmjj_jjyy

    Unfortunately it's still not resolved - I think what Gabriel Michaud was saying is that a nullable DateTime deserialises correctly - which I've also seen work.

    The only problem is that this doesn't apply to all types. For example a nullable int deserialises to null even if there is a value. The next post by Joe Giardino seems to confirm this and mentions a new release which will fix the bug. The problem is that there has been a release of the Storage Client ( this week that has not resolved this issue.



    Thursday, November 15, 2012 9:04 AM
  • I've done some tests and the following data types always return null even if the table contains values:

    Int32?, Int64?, Guid?, Double?

    The following return values correctly:

    String, DateTime?



    Thursday, November 15, 2012 9:26 PM
  • Hi,

    This is a known issue that we're working on. Please see Jai Haridas's reply in below post:


    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us

    • Marked as answer by Johnson - MSFT Monday, November 19, 2012 2:36 AM
    • Unmarked as answer by DavidM51 Monday, November 19, 2012 12:04 PM
    Friday, November 16, 2012 5:54 AM
  • Thanks Allen

    According to Joe Giardino's post on the comments section here: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx - there was a fix that was due this week.

    Here's the quote (8 Nov):


    You are correct, both DateTime and DateTimeOffset are current supported for nullable types. Unfortunately some primitive types are not currently supported. This issue has been fixed and is currently in testing / signing. Please check github / nuget mid next week for the updated binaries.


    The update this week ( didn't fix the bug. Do you have an estimate as to when this will be fixed?



    Friday, November 16, 2012 8:14 AM
  • Let me consult internally to see what the problem is.

    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us

    Friday, November 16, 2012 9:39 AM
  • Yes. This is an issue which has been fixed now but is currently in testing. It will go out as part of 2.0.2 by the end of this month. The earlier fix that was released this week( basically fixed the following 3 bugs :

    •         CloudStorageAccount.*Parse methods throws an exception for “UseDevelopmentStorage=true” string
    •         StorageErrorCodeStrings class is missing
    •         ICloudBlob interface does not have GetSharedAccessSignature method

    We will be updating the Azure storage team blog when 2.0.2 is released to git/nuget. Sorry for the confusion.

    • Edited by Veena Udayabhanu Friday, November 16, 2012 5:50 PM
    • Marked as answer by Johnson - MSFT Monday, November 19, 2012 2:36 AM
    • Unmarked as answer by DavidM51 Monday, November 19, 2012 11:59 AM
    • Marked as answer by DavidM51 Monday, November 19, 2012 1:32 PM
    • Unmarked as answer by DavidM51 Saturday, December 1, 2012 12:13 PM
    Friday, November 16, 2012 5:50 PM
  • As part of this fix, will EntityProperty be updated to support nullable values for all basic types?
    Monday, November 26, 2012 9:49 AM
  • Hi Veena

    It's now December 1st and version 2.0.2 is still not on nuget and there are no new posts on the storage blog. 

    Do you have a new date for this release?



    Saturday, December 1, 2012 12:11 PM
  • Hi

    Could anyone from Microsoft please provide an answer to this?



    Tuesday, December 4, 2012 1:58 AM
  • Hi

    We need to perform a release by the end of the month. Should we revert to the old client library or wait for version 2.0.2?

    I would really appreciate some kind of answer from Microsoft on this - our release schedules have already been affected by the no show of 2.0.2 at the end of November.



    Wednesday, December 5, 2012 12:48 PM
  • Thank you for reporting this issue. We apologize for the inconvenience. We will have the fix in Storage Client Library 2.0.3.

    In the meantime, to work around this problem (where you need to use nullable types), you can use the legacy Table Service implementation as also described in the Migration Guide.

    Thursday, December 6, 2012 4:49 AM
  • Thanks Serdar Do you have a release date for 2.0.3? As you seem to be confirming - and I've found by experimentation - 2.0.2 doesn't fix the nullable values bug. Cheers David
    Friday, December 7, 2012 12:37 AM
  • We have the fix ready. Storage Client Library 2.0.3 is currently in testing and will be released soon.

    For more information on what is/will be fixed in which release, please refer to Known Issues for Windows Azure Storage Client Library 2.0 for .NET and Windows Runtime blog post.

    • Marked as answer by Allen Chen - MSFT Monday, December 17, 2012 2:42 AM
    • Unmarked as answer by DavidM51 Tuesday, December 18, 2012 8:26 PM
    Monday, December 10, 2012 9:11 PM
  • Storage Client Library 2.0.3 is now released on NuGet and GitHub.
    • Marked as answer by DavidM51 Tuesday, December 18, 2012 8:26 PM
    Monday, December 17, 2012 6:13 PM