22

I'm trying to consume a RESTful web service using WCF. I have no control over the format of the web service, so I have to make a few workarounds here and there. One major problem I cannot seem to get around, however, is how to make WCF deserialize an enum as a string.

This is my code (names changed, obviously):

[DataContract]
public enum Foo
{
    [EnumMember( Value = "bar" )]
    Bar,

    [EnumMember( Value = "baz" )]
    Baz
}

[DataContract]
public class UNameIt
{
    [DataMember( Name = "id" )]
    public long Id { get; private set; }

    [DataMember( Name = "name" )]
    public string Name { get; private set; }

    [DataMember( Name = "foo" )]
    public Foo Foo { get; private set; }
}

And this is the returned data that fails deserialization:

{
     "id":123456,
     "name":"John Doe",
     "foo":"bar"
}

Finally, the exception thrown:

There was an error deserializing the object of type Service.Foo. The value 'bar' cannot be parsed as the type 'Int64'.

I do not want to switch to using the XmlSerializer, because, among its many other shortcomings, it won't let me have private setters on properties.

How do I make WCF (or, well, the DataContractSerializer) treat my enum as string values?

EDIT: Doing this seems to be impossible, and the behavior is the way it is by design. Thank you Microsoft, for not giving us options, having to resort to hacks. Doing it the way somori suggests seems to be the only way to get string enums with JSON and WCF.

Alex
  • 3,429
  • 4
  • 36
  • 66
  • Have you tried building a UNameIt object in code and using the DataContractSerializer to serialize (and then deserialize it) to see if maybe the serialization mismatches the message you receive? – GaussZ Jan 27 '10 at 09:53
  • The thing is, I'm not the one doing the serialization. This JSON comes from a third party. I can't control anything about it, the only thing I have control over is the deserialization, except I guess not, because I can't get WCF to deserialize an enum the way these guys set up enums. I wish the DataContractSerializer was more flexible. – Alex Jan 27 '10 at 12:00
  • Yes I understand that you have no control over it, it would maybe hint at the problem though if you could compare a self-serialized object with what you get from the third party to understand why the serializer does not like it. – GaussZ Jan 27 '10 at 12:55
  • Try to avoid expose enums in wcf data contracts because they create subtle backwards compatible problems. See http://stackoverflow.com/questions/326339/do-you-use-enum-types-in-your-wcf-web-services – Michael Freidgeim Jul 21 '13 at 09:01
  • 1
    @nawfal If you pay attention, you'll see that this question was asked two months before the one you're referring to. If anything, that one is a possible duplicate of this one. – Alex Jul 17 '14 at 12:45
  • @Alex the accepted policy of SO is that you can close [the older q with the newer one if latter has-received-more attention/is-better-worded etc](http://meta.stackoverflow.com/questions/251938/should-i-flag-a-question-as-duplicate-if-it-has-received-better-answers). That said I retract my close vote because this is about `DataContractSerializer` in WCF context while the other is about `JavascriptSerializer` in ASP.NET. I should be more careful! :) – nawfal Jul 17 '14 at 12:56
  • @Alex are you using `DataContractSerializer` or `DataContractJsonSerializer` ? – nawfal Jul 17 '14 at 13:02
  • I don't even remember, this was over four years ago. – Alex Jul 17 '14 at 14:52

3 Answers3

8

This might be a silly question.

What happens if you do

[DataMember( Name = "foo" )]
private string foo { get; private set; }

public Foo Foo 
{ 
  get 
  {
    return Foo.Parse(foo);
  }
}

?

Simon Gill
  • 1,096
  • 9
  • 22
  • 3
    I've tried that already, and that works, but it's a hack, and if it can be avoided, I want to avoid it. – Alex Jan 28 '10 at 07:01
  • 1
    Actually, this seems to be the only way to do it, see http://stackoverflow.com/questions/794838/datacontractjsonserializer-and-enums/794962#794962 – Alex Jan 28 '10 at 07:15
  • You would need a setter also, wouldn't you? – Ruan Mendes Apr 29 '14 at 18:01
  • Sorry for the much too late reply, @JuanMendes, but no, not for the specific use case I had. The deserializer would only write to the `foo` property, and since I only needed deserialization, I'd only need to read the `Foo` value, never set it. – Alex Mar 21 '18 at 06:01
1

I know this is an old post, but I think it worth mentioning.

I received a similar error where the deserialization of the json string failed, seeming to deserialize to the wrong types.

The fix for me was to simply URL encode the json string before sending it to the server. A simple but easy mistake to make.

HttpUtility.UrlEncode(JSONInstruction) /*remember to encode the string*/
0

Er..? Aren't enums integer? The exception is valid. I dunno if this helps: http://msdn.microsoft.com/en-us/library/aa347875.aspx

  • No, it's not. Have you read that article yourself? Here's an interesting excerpt: Generally the data contract includes enumeration member names, not numerical values. However, when using the data contract model, if the receiving side is a WCF client, the exported schema preserves the numerical values. The problem is, I'm being a WCF client. However, the server uses string enums. I'm a little stumped... – Alex Jan 23 '10 at 07:29
  • Could the server code be buggy? Is it possible to use data structure in this instance? –  Jan 23 '10 at 13:58
  • The server is not a WCF service, I think it runs Python. I can't change the way they do things, I'm just a consumer in this scenario, and I have to go by their rules. – Alex Jan 27 '10 at 12:01