1
ZioCain
4y

Can someone please explain me why the fuck the following doesn't work in C#?

Dictionary<string,object> mex=Json.Deserialize(data.ToString())as Dictionary<string,object>;
if(mex.ContainsKey("sessionId") && mex["sessionId"].ToString()!=tkn.GetSessionID())

the previous condition is NEVER true, but the following:

Dictionary<string,object> mex=Json.Deserialize(data.ToString())as Dictionary<string,object>;
if(mex.ContainsKey("sessionId") && mex["sessionId"]!=tkn.GetSessionID())

will actually work as expected.

tkn.GetSessionID() returns a string, of course
and mex["sessionId"] is always an object that contains a string in form of a number, like 152, 552, 6246 and so on and no, it won't ever contain any blank or other character

Fuck this fucking shit from C#

Comments
  • 0
    Try the Equals method for comparing strings
  • 1
    Well you could easily step through with a debugger and test, but for starters .ToString() does not always behave nicely with [object], though I'm not sure how it's letting you compare object to string to begin with unless it is reducing your string to its' base object type or doing bitwise comparison on the objects - which could end up giving you false negatives.
  • 0
    @ArcaneEye I really don't know, btw without using the ToString() method it works flawlessly (it's been working for 6 months now with no issues)
  • 1
    @scor it's actually C#, not C, but yeah, there's an implicit ToString used to compare the thing in order to make the evaluation possible. Unless it is using something like "ToObject()" which doesn't really exists, but...
  • 1
    I can say with a fairly high degree of certainty your issue is localized to what's being deserialized.

    The root of this lies in the object typing of the value argument. You generally want to avoid that unless you're working with the Dynamic namespace (expandoobject, etc).

    When coupled to the deserializer, you're telling it:

    "Hey, roll over this json object and take your best guess at what the internalized value is."

    At that point, it's an implementation detail of the deserialization library as to what happens. It could try to intelligently determine that "value" is a string and 10 is an int. Object will allow this since both types are based on System.Object.

    Due to this, you don't know what you have at runtime.

    There isn't a test where your code would fail in the given scenario if it were always a string, see attached gist and test screenshot.

    Tests can run in linqpad
    https://gist.github.com/FailedCheck...
  • 1
    @SortOfTested that's quite interesting! I hardly ever do stuff like these to out stuff.

    Did you do it all just to answer me? If so, thank you VERY VERY MUCH! It's much appreciated! I'll look at it with my code tomorrow to check if I can optimize something there by strictly typing the result of deserialization
  • 2
    @ZioCain
    No biggie, hope it helps!
  • 0
    Yeah, there's no way from just looking at the code to know what type or types of things are stored as the dictionary values.
Add Comment