CODEWITHSUNDEEP
c#azureazure-table-storage
Peter Oehlert
Peter Oehlert

Reputation: 16958

TableServiceContext: Can't cast to unsupported type 'DateTimeOffset' exception when serializing

I've been trying to get a new MVC web role setup for Azure, connected to Azure Table Services. I've used the 1.8 Azure SDK and the Azure project template in VS 2012. I updated all nuget packages to the latest, though I still suspect there is something at issue with the WCF support for DateTimeOffset which is new in version 5.

I have a dirt simple object like so:

[DataServiceEntity()]
[DataServiceKey("PartitionKey", "RowKey")]
public class AppUser : TableEntity
{
}

I have an MVC action to create a new AppUser that looks like this:

var connectionString = CloudConfigurationManager.GetSetting("DataStorageConnectionString");
var storageAccount = CloudStorageAccount.Parse(connectionString);
var tableClient = storageAccount.CreateCloudTableClient();
var ctx = new TableServiceContext(tableClient);

ctx.AddObject("Users", user);
var response = ctx.SaveChanges();

When this code executes in my MVC web role, the result of my connectString is UseDevelopmentStorage=true.

The SaveChanges call results in the following exception:

System.NotSupportedException was caught
  HResult=-2146233067
  Message=Can't cast to unsupported type 'DateTimeOffset'
  Source=System.Data.Services.Client
  StackTrace:
       at System.Data.Services.Client.ClientConvert.GetEdmType(Type propertyType)
       at System.Data.Services.Client.DataServiceContext.WriteContentProperty(XmlWriter writer, String namespaceName, ClientProperty property, Object propertyValue)
       at System.Data.Services.Client.DataServiceContext.WriteContentProperties(XmlWriter writer, ClientType type, Object resource, EpmSourcePathSegment currentSegment, Boolean& propertiesWritten)
       at System.Data.Services.Client.DataServiceContext.CreateRequestData(EntityDescriptor box, Boolean newline)
       at System.Data.Services.Client.DataServiceContext.SaveResult.CreateChangeData(Int32 index, Boolean newline)
       at System.Data.Services.Client.DataServiceContext.SaveResult.BeginNextChange(Boolean replaceOnUpdate)
       at System.Data.Services.Client.DataServiceContext.SaveChanges(SaveChangesOptions options)
       at MvcWebRole1.Controllers.UserController.Create(AppUser user) in c:\src\Azure1\MvcWebRole1\Controllers\UserController.cs:line 67
  InnerException:

When looking at TableEntity, the Timestamp property is of type DateTimeOffset. I've been investigating the idea that one of the dependencies in my build out is old and causing issues but I haven't been able to identify any old versions. As far as I can tell, I'm using the latest version of the SDK, latest version of the project template, and updated all of the packages so I'm a little at a loss now.

** Update 12/26 **

I created a new console app for testing with just the storage client and was able to replicate the behavior perfectly. The Azure Storage Client nuget package was only released a little more than a week ago, perhaps it was not intended to come out yet. I can't get it to work with the dev storage or with live Azure, but reverting to the 1.7 assembly which came with both the 1.8 and 1.7 SDK from Oct and Jun respectively requires a bit of a rewrite but it does work with both dev storage and Azure.

Upvotes: 3

Views: 1289

Answers (2)

Curt Hagenlocher
Curt Hagenlocher

Reputation: 20916

It looks to me like you’re mixing access methods. TableServiceContext is from the 1.x storage API, while TableEntity is from the 2.0 storage API.

If you want to use the 1.x library, derive from TableServiceEntity instead of TableEntity and don’t use those attributes. If you want to use the 2.0 library, use a CloudTable and a TableOperation instead of a TableServiceContext.

Upvotes: 2

Igorek
Igorek

Reputation: 15860

Have you tried not deriving from TableEntity and simply implementing your own PartitionKey/RowKey properties as strings and Timestamp as DateTime?

Also, try testing against real Azure storage account. Over the last few years, I found the emulation storage account to not be a useful test bed for serious Azure storage development.

Upvotes: 2

Related Questions