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

Reply via email to