Oh, also needed to change all generated classes for descriptor.proto from internal to public...
On Wednesday, December 2, 2015 at 8:56:12 AM UTC-8, James Hugard wrote: > > Hi Jon: > > Pity that there will be no official support. That means I shall be unable > to have fully self-describing messages. Further, I believe that will also > preclude writing proto compiler plugins in C# (F#, VB, etc.). > > As an interim solution (or a permanent one?), I have hand-edited > Descriptor.proto to remove everything incompatible with proto3, compiled it > with proto3 syntax, thus generating C# code. The main issue is support for > extension ranges - without those, it is impossible to declare custom > options (which we also use). Therefore, I simply compiled all other proto > files using the original (proto2) descriptor.proto file then hand edited > the generated code to reference > Google.ProtocolBuffers.DescriptorProtos.FileDescriptorProto. > > Less than ideal, and certainly not acceptable for production use. > > I'm eyeing the Froto <https://github.com/ctaggart/froto> project as a > possible long-term solution, but with a need to support many languages > that's also less than ideal and would take .NET out of the primary > ecosystem. > > Thanks for the reply! > > jh > > > On Wednesday, December 2, 2015 at 6:46:52 AM UTC-8, Jon Skeet wrote: >> >> On Wednesday, 2 December 2015 04:45:30 UTC, James Hugard wrote: >>> >>> Trying to use a FileDescriptorSet in my own proto3 message definition >>> with C# 3.0.0-alpha4 generated code, but running into compilation issues. >>> >>> The code generates just fine using protoc.exe, but the generated code >>> won't compile due to a missing reference to "global >>> ::Google.Protobuf.FileDescriptorSet". >>> >>> Attempting to generate code from the protobuf definition fails, because >>> the Descriptor.proto file uses proto2 syntax and hence is not supported by >>> the C# code generator. >>> >>> A C# object for FileDescriptorSet does not appear to be in >>> Google.Protobuf assembly. Nor could I figure out how to modify the >>> generated code to compile properly. Attempting to manually edit the >>> generated code to use >>> >>> Google.Protobuf.Collections.RepeatedField< >>> Google.Protobuf.Reflection.FileDescriptor > failed with a "no >>> conversion to IMessage<>", or something similar. >>> >>> >>> Please, what is the right way to use a FileDescriptorSet in my own proto? >>> >> >> I'm afraid you can't. We generate the code for descriptor.proto so that >> we can use it within the protobuf runtime, but it's all internal - we don't >> have any codegen to support proto2 semantics, and we've carefully looked at >> what we need from descriptor.proto to check that it's okay with what we >> need to use it for internally, but that's all. It would be a bad idea to >> expose it separately. >> >> If we ever retroactively fit proto2 support, that would be fine, of >> course - but until then, I'm afraid there's no way of doing this. You could >> create your own proto3 copy of descriptor.proto, taking only the bits you >> care about, and if you're very careful you *may* then be able to >> interoperate with code that actually expects a FileDescriptorSet... but you >> would definitely need to be careful. >> >> Jon >> >> > -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
