it does support GetExtension like c++

[LazyPlanet]

import "google/protobuf/descriptor.proto";

extend google.protobuf.MessageOptions {

optional string my_option = 51234;

}

message MyMessage {

option (my_option) = "Hello world!";

}

string value = MyMessage::descriptor()->options().GetExtension(my_option);

how c# can do that?

[jskeet]

No - extensions are only supported in proto2, and the C# implementation only supports proto3.

[LazyPlanet]

thank u for your reply, but when i write

syntax = "proto3";
import "google/protobuf/descriptor.proto";
extend google.protobuf.MessageOptions {
string my_option = 51234;
}
message MyMessage {
option (my_option) = "Hello world!";
}

How can i get my_option value("Hello world!") from MyMessage? Does it support this?
Thank you very much.

[jskeet]

I don't think so, no. The parser ignores any fields it doesn't understand, which would include my_option. If we do want to support it, I think it would only be for options like this, rather than general extensions.

@xfxyjwf I haven't heard about this being a requirement for proto3 code - thoughts?

[LazyPlanet]

I saw it at : https://developers.google.com/protocol-buffers/docs/proto3#options
It said as below:

Custom Options

Protocol Buffers also allows you to define and use your own options. This is an advanced feature which most people don't need. If you do think you need to create your own options, see the Proto2 Language Guide for details. Note that creating custom options uses extensions, which are permitted only for custom options in proto3.

I think "Custom Options" is a very good point. And supported in proto3. But in csharp I can not find.

Detail info : https://developers.google.com/protocol-buffers/docs/proto#customoptions

Thank u for your time.

[jskeet]

Right, I'm almost entirely certain that we don't support it at the moment. Hopefully Feng Xiao can comment on whether this is required for GA or whether we can add it later.

[LazyPlanet]

Sorry to hear that.
I found that there are many class with options in Google.Protobuf.Reflection.Descriptor but with key world "internal " , I don not know why.

I want to know whether you will add it, and when will it work...If you would not support it. I plan to do it, while it is very hard for me, haha...So should you give me an answer?
Thank u very much.

[jskeet]

The descriptor proto representations are internal for two reasons:

• They are proto2 but are interpreted by code designed for proto3, and while we've made sure that our code handles the differences between proto2 and proto3, we don't want to expose that externally
• All C# messages are mutable, and we don't want to allow the internal data structures to be mutated

Basically, information about descriptors is exposed via MessageDescriptor etc. So I'd expect that if we did this at all, it would be via methods in MessageDescriptor, FieldDescriptor etc.

We'll update this issue with plans, but that's not my decision to make.

[LazyPlanet]

Thank u for your time, Waiting for Feng Xiao to answer..

[xfxyjwf]

I think we will eventually support accessing custom options in proto3. It's not a requirement for GA though as it's an advanced feature that most users probably don't even know about. Currently only languages that support proto2 extensions allow access to custom options.

[LazyPlanet]

May I know how long can I use this feature? For in my project I will use it...
If you do not have time, May I join you to complete it?
Thank u very much..

[jskeet]

Well, pull requests are always welcome, but we mustn't expose the underlying proto objects here. I'd expect some method specifying a field number and a type to deserialize the option as.

[jskeet]

Closing this as a duplicate of #2143.