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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
