1. 21 Feb, 2019 1 commit
  2. 08 Oct, 2018 1 commit
    • Benjamin Krämer's avatar
      Ported FieldMaskUtil from Java to C# (#5045) · 80e530da
      Benjamin Krämer authored
      * Ported FieldMaskUtil from Java to C#
      
      * Merged FieldMaskUtil into FieldMaskPartial
      
      - Removed FieldMaskUtil
      - Moved FieldMaskTree to root
      - Updated tests
      
      * Improved tests
      
      - Removed internal method FieldMaskTree.GetFieldPaths
      - Proof FieldMask.Paths only contains expected values
      
      * Added FieldMaskTreeTest to Makefile
      
      * Added FieldMaskTree to Makefile
      80e530da
  3. 25 Jun, 2018 1 commit
  4. 24 Mar, 2017 1 commit
  5. 28 Feb, 2017 1 commit
  6. 23 Feb, 2017 1 commit
    • John Brock's avatar
      Fixes for .NET 3.5 compatibility · c9b2c8f3
      John Brock authored
      * Changing DOTNET35 framework symbols in preprocessor directives to the default built-in value of NET35.
      * Adding extension method StreamExtension.CopyTo for .NET 3.5 because it didn’t exist until .NET 4, and adding associated unit tests.
      c9b2c8f3
  7. 03 Nov, 2016 1 commit
    • Jon Skeet's avatar
      Change JSON field name formatting · 50a37e01
      Jon Skeet authored
      This affects cases with leading capital letters.
      
      This breaks compatibility with previous C# releases, but
      fixes compatibility with other implementations.
      
      See #2278 for details.
      50a37e01
  8. 27 Jul, 2016 2 commits
  9. 28 Jun, 2016 1 commit
  10. 23 Jun, 2016 1 commit
  11. 29 Apr, 2016 1 commit
  12. 20 Apr, 2016 1 commit
  13. 29 Mar, 2016 1 commit
  14. 18 Mar, 2016 1 commit
  15. 07 Mar, 2016 1 commit
  16. 04 Feb, 2016 1 commit
  17. 20 Jan, 2016 1 commit
    • Jon Skeet's avatar
      Ensure that FieldMask, Timestamp and Duration ToString() calls don't throw · dd43dcca
      Jon Skeet authored
      The usage of ICustomDiagnosticMessage here is non-essential - ToDiagnosticString
      doesn't actually get called by ToString() in this case, due to JsonFormatter code. It was
      intended to make it clearer that it *did* have a custom format... but then arguably I should
      do the same for Value, Struct, Any etc.
      
      Moving some of the code out of JsonFormatter and into Duration/Timestamp/FieldMask likewise
      feels somewhat nice, somewhat nasty... basically there are JSON-specific bits of formatting, but
      also domain-specific bits of computation. <sigh>
      
      Thoughts welcome.
      dd43dcca
  18. 15 Jan, 2016 3 commits
  19. 13 Jan, 2016 1 commit
  20. 06 Jan, 2016 1 commit
  21. 15 Dec, 2015 1 commit
    • Jon Skeet's avatar
      Make ToString() valid without a type registry · aabc6c41
      Jon Skeet authored
      This addresses issue #1008, by creating a JsonFormatter which is private and only different
      to JsonFormatter.Default in terms of reference equality.
      
      Other plausible designs:
      
      - The same, but expose the diagnostic-only formatter
      - Add something to settings to say "I don't have a type registry at all"
      - Change the behaviour of JsonFormatter.Default (bad idea IMO, as we really *don't* want the result of this used as regular JSON to be parsed)
      
      Note that just trying to find a separate fix to issue #933 and using that to override Any.ToString() differently wouldn't work for messages that *contain* an Any.
      
      Generated code changes follow in the next commit.
      aabc6c41
  22. 02 Dec, 2015 2 commits
    • Jon Skeet's avatar
      Handle JSON parsing for Any. · 3de2fced
      Jon Skeet authored
      This required a rework of the tokenizer to allow for a "replaying" tokenizer, basically in case the @type value comes after the data itself. This rework is nice in some ways (all the pushback and object depth logic in one place) but is a little fragile in terms of token push-back when using the replay tokenizer. It'll be fine for the scenario we need it for, but we should be careful...
      3de2fced
    • Jon Skeet's avatar
      JSON formatting for Any. · 567579b5
      Jon Skeet authored
      567579b5
  23. 22 Nov, 2015 1 commit
    • Jon Skeet's avatar
      Tidy up reflection in advance of attempting to implement DynamicMessage. · 72ec3367
      Jon Skeet authored
      There are corner cases where MessageDescriptor.{ClrType,Parser} will return null, and these are now documented. However, normally they *should* be implemented, even for descriptors of for dynamic messages. Ditto FieldDescriptor.Accessor.
      We'll still need a fair amount of work to implement dynamic messages, but this change means that the public API will be remain intact.
      
      Additionally, this change starts making use of C# 6 features in the files that it touches. This is far from exhaustive, and later PRs will have more.
      
      Generated code changes coming in the next commit.
      72ec3367
  24. 09 Nov, 2015 1 commit
  25. 03 Nov, 2015 1 commit
    • Jon Skeet's avatar
      Implement JSON parsing in C#. · fb248822
      Jon Skeet authored
      This includes all the well-known types except Any.
      Some aspects are likely to require further work when the details of the JSON parsing expectations are hammered out in more detail. Some of these have "ignored" tests already.
      
      Note that the choice *not* to use Json.NET was made for two reasons:
      - Going from 0 dependencies to 1 dependency is a big hit, and there's not much benefit here
      - Json.NET parses more leniently than we'd want; accommodating that would be nearly as much work as writing the tokenizer
      This only really affects the JsonTokenizer, which could be replaced by Json.NET. The JsonParser code would be about the same length with Json.NET... but I wouldn't be as confident in it.
      fb248822
  26. 01 Oct, 2015 1 commit
    • Jon Skeet's avatar
      Support ToString in RepeatedField and MapField. · 9ed6d4da
      Jon Skeet authored
      This changes how we approach JSON formatting in general - instead of looking  at the field a value came from, we just look at the type of the value. It's possible this *could* be slightly inefficient, but if we start caring about JSON performance deeply, we'll probably want to rewrite all of this anyway. It's definitely simpler this way.
      
      When we support dynamic messages, we'll need to modify JsonFormatter to handle enum values, as they won't come be "real" .NET enums at that point. It shouldn't be hard to do though.
      9ed6d4da
  27. 08 Aug, 2015 1 commit
  28. 04 Aug, 2015 2 commits
  29. 03 Aug, 2015 4 commits
  30. 31 Jul, 2015 1 commit
  31. 30 Jul, 2015 1 commit
  32. 22 Jul, 2015 1 commit
    • Jon Skeet's avatar
      Implemented Jan's suggestion of FieldCollection, replacing FieldAccessorCollection. · c1c6b2d0
      Jon Skeet authored
      I think Jan was actually suggesting keeping both, but that feels redundant to me. The test diff is misleading here IMO, because I wouldn't expect real code using reflection to use several accessors one after another like this, unless it was within a loop. Evidence to the contrary would be welcome :)
      
      This change also incidentally goes part way to fixing the issue of the JSON formatter not writing out the fields in field number order - with this change, it does except for oneofs, which we can fix in a follow-up change.
      
      I haven't actually added a test with a message with fields deliberately out of order - I'm happy to do so though. It feels like it would make sense to be in google/src/protobuf, but it's not entirely clear what the rules of engagement are for adding new messages there. (unittest_proto3.proto?)
      c1c6b2d0