we receive a JSON string from our ESB that was converted from XML. Since the XML node has no type info, the converted string has data in it like...
"ClientId" : "13579"
The POCO we're deserializing in to has a property...
public int ClientId { get; set; }
Is there any way to tell the deserializer to parse the integer? Preference would be for no annotations in the POCO, and the deserializer should not have direct knowledge of the POCO type.
Thanks!!
Turns out it DOES parse the integer, as Andrew mentioned. The issue was caused by the string having an extra set of "{" "}" surrounding the actual details. These appear to be the result of an XML->JSON conversion happening in the service bus layer. If those are removed, it all seems to be happy :)
Related
I follow the usual recommendations of serializing javascript Date objects to be sent to the server by using the toISODate js function.
In fact Breeze.js is doing this for me which is great. Everything works as expected when the property on my Entity is a DateTime - the date gets saved to the database as a UTC (0 offset date) datetime.
I hit a problem when the property on the Entity is of type string. A date that is sent over the wire as '2013-06-08T23:00:00Z' is being deserialized into the string property on the Entity as '06/08/2013 23:00:00' and this is the same value that is saved into the varchar backing column in the database.
So the date is being deserialized into a 'en-US' formatted date (MM/dd/yyyy HH:mm:ss). I'm stuck as to why this is happening or how to change things so that the string remains intact as it's deserialized into a string property.
A few technical notes:
I confirmed the deserialized value in the property by wiring up a BeforeSaveEntitiesDelegate to the EFContextProvider and inspected the Entity instance in the debugger just before it was saved
when inspecting the entity in the BeforeSaveEntitiesDelegate method on the server, I noted that the Thread.CurrentThread.CurrentCulture and CurrentUICulture were both 'en-GB'
for technical reasons I need to use a string property rather than a DateTime (or DateTimeOffset) - basically the property could receive any type of data so string is the universal format that will fit everything.
Help would be most welcome!
Thanks
Christian Crowhurst
For a .NET server, Breeze uses JSON.net to serialize/deserialize json. Breeze allows you to configure this by automatically detecting any 'custom' implementations of the 'BreezeConfig' class.
This means that you can customize Breeze's use of JSON.Net's serialization behavior by implementing a subclass of BreezeConfig. This might look something like this within your server project.
using Breeze.ContextProvider;
using Breeze.WebApi2;
using Newtonsoft.Json;
namespace Sample_WebApi2 {
public class CustomBreezeConfig : BreezeConfig {
/// <summary>
/// Override to use a specialized JsonSerializer implementation.
/// </summary>
protected override JsonSerializerSettings CreateJsonSerializerSettings() {
// get the breeze default settings.
var baseSettings = base.CreateJsonSerializerSettings();
// Not sure if this is the setting you want but...
baseSettings.DateParseHandling = DateParseHandling.None;
return baseSettings;
}
}
In the hopes of supplying more metadata to my application, I wanted to wrap some extra information around my database queries (using plain on SQL data access, no Entity Framework or other ORMs).
I have an APIQueryResult object set up as:
string Status { get; set; }
string[] Errors { get; set; }
object[] Data { get; set;}
The Data is an array of my POCO object(s).
If I request JSON, then everything serializes just fine, including my metadata + object data. However, if I request XML, then I get the following error:
The 'ObjectContent`1' type failed to serialize the response body for
content type 'application/xml; charset=utf-8'.
Note: This idea was inspired by Filip W (http://www.strathweb.com/2012/06/extending-your-asp-net-web-api-responses-with-useful-metadata/ ) but I didn't want to get as complicated as writing HttpHandlers, etc.
Is there a better way to provide at least error information back to the client if I can't return a normal class, or IEnumerable/List of class instances?
Thanks!
You could implement IXmlSerializable on your APIQueryResult object. With a bit of reflection it shouldn't be more than 20-30 lines with an XmlWriter to manually serialize that information. I guess it depends on how complex your DTOs are. The advantage of that is you have complete control over how what your XML looks like.
I have a class with several properties all defined in sentence case:
Public Class Provider
Public Property ProviderName As String
End Class
I need to be able to pass instances of this through AJAX which I will then be using in JavaScript to add to an array, process etc. Currently I am using the DataContractJsonSerializer to serialize to JSON and return through an ASHX handler. It may just be me being picky, but I don't really like having sentence case properties in JavaScript, I would prefer them all to be lower case, to produce the following:
alert(myProvider.providername);
With the default DataContractJsonSerializer I simply cannot find a way to do this! With JSON.NET it would appear that it is a simple task, but unfortunately I can't introduce another dependency into this project - as much as I would like to.
Does anybody know of any way to override the format of keys that are generated?
The project is using ASP.NET Web Forms 4.0.
Thanks,
Chris.
It's possible to customize the DataMember attribute to use a lowercase name. Here's the syntax in C#, I assume in VB should be similar:
[DataMember(Name = "title")]
public string Title { get; set; }
I'm retrieving an GUID from a webservice with Flex.
With this GUID i have to retrieve an Username from the webservice.
The output gives me a "The key supplied is invalid. It must be of type System.Guid."
I looked everywhere for a solution, but I can't find the right answer.
Anyone?
Thanks!
edited: Is there a way to convert a string to a GUID in AS3?
I don't think you'll need to do this on the client. The problem is that you are sending a string to the server and that it requires an instance of System.Guid there and not a string. You can pass the string to the constructor of System.Guid to create a valid guid from the given string.
I'm seeing a very strange issue with a .NET webservice being consumed by Flex.
I have a very simple class with nothing other than properties with [XmlAttribute('xxx')] attributes.
public class OrderAddress
{
public OrderAddress() {}
[XmlAttribute("firstName")]
public string FirstName { get; set; }
[XmlAttribute("lastName")]
public string LastName { get; set; }
[XmlAttribute("company")]
public string Company { get; set; }
[XmlAttribute("address1")]
public string Address1 { get; set; }
... (more properties)
}
The problem is that in Flex when this object is deserialized EVERY SINGLE fields is null in the debugger. The instance of the OrderAddress class is not null, just all the fields. I an 100% sure my web service proxy layer is up to date and there is 100% definitely data going across the wire as shown by Fiddler.
The very very wierd thing is that if I change one of these properties to serialize as an element (as opposed to XmlAttribute) and recompile ONLY my C# webservice then the data instantly can be recognized by Flex. If I add a completely unused field - like public string Foo = "foo"; then that also suddenly works.
I kind of remember seeing something like this before but don't remeber if I successfully fixed it or not.
Its 3:30am for me and I need to postpone my hardcore troubleshooting, but throwing this out here in case its obvious to anyone reading. The code is in a module, which I know can sometimes cause some wierdness - but this seems to be very wierd.
After three days' struggling, finally I figured out this XML attribute was the cause of my problem. Slightly different from yours, my class has an array of objects in addition to the XML attribute. Flex was able to generate proxies, and even got attribute correctly (it was treated as a property), but it failed to deserialize the XML elements (returned from web serive) to array of objects. Once I delete that attribute, everything worked fine...so yes, this is "element centric XML serialization". But, is there any way to work around it?
Elements centric XML is more interoperable format in XML serialization.
This is the reason that the new WCF DataContract serializer serializes every property as elements instead of attribute. Attribute to me is descriptor to the element rather than data for the element.