C# protobuf doesn't support proto2, which all of the descriptor aspects are based on.
We've included minimal support for fetching options at the moment - just enough so it's *possible*. But yes, it's far from as clean as it could be. Rather than just exposing the constants, I'd rather revisit how options are exposed entirely - which should also be done in the light of the possibility of supporting proto2 completely (as per this issue <https://github.com/google/protobuf/issues/4407>). Basically, it's a matter of being very conservative about the API we expose. That's painful in the short term, but better in the long term. Jon On Saturday, 5 May 2018 00:56:41 UTC+1, Jeremy Swigart wrote: > > Anyone know why generated C# classes don't include the named constants for > options? (MessageOptions,FieldOptions,etc). > > They still work but you have to hard code the number value directly, which > is less that readable and isn't on par with the named constants generated > for the C++ files. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
