Google.Protobuf.Reflection.FileOptions
public sealed class FileOptions : IExtendableMessage<FileOptions>, IMessage<FileOptions>, IMessage, IEquatable<FileOptions>, IDeepCloneable<FileOptions>, IBufferMessage
Container for nested types declared in the FileOptions message type.
Field number for the "cc_enable_arenas" field.
Field number for the "cc_generic_services" field.
Field number for the "csharp_namespace" field.
Field number for the "deprecated" field.
Field number for the "features" field.
Field number for the "go_package" field.
Field number for the "java_generate_equals_and_hash" field.
Field number for the "java_generic_services" field.
Field number for the "java_multiple_files" field.
Field number for the "java_outer_classname" field.
Field number for the "java_package" field.
Field number for the "java_string_check_utf8" field.
Field number for the "objc_class_prefix" field.
Field number for the "optimize_for" field.
Field number for the "php_class_prefix" field.
Field number for the "php_metadata_namespace" field.
Field number for the "php_namespace" field.
Field number for the "py_generic_services" field.
Field number for the "ruby_package" field.
Field number for the "swift_prefix" field.
Field number for the "uninterpreted_option" field.
Enables the use of arenas for the proto messages in this file. This applies
only to generated classes for C++.
Should generic services be generated in each language? "Generic" services
are not specific to any particular RPC system. They are generated by the
main code generators in each language (without additional plugins).
Generic services were the only kind of service generation supported by
early versions of google.protobuf.
Generic services are now considered deprecated in favor of using plugins
that generate code specific to your particular RPC system. Therefore,
these default to false. Old code which depends on generic services should
explicitly set them to true.
Namespace for generated classes; defaults to the package.
Is this file deprecated?
Depending on the target platform, this can emit Deprecated annotations
for everything in the file, or it will be completely ignored; in the very
least, this is a formalization for deprecating files.
Any features defined in the specific edition.
WARNING: This field should only be used by protobuf plugins or special
cases like the proto compiler. Other uses are discouraged and
developers should rely on the protoreflect APIs for their client language.
Sets the Go package where structs generated from this .proto will be
placed. If omitted, the Go package will be derived from the following:
- The basename of the package import path, if provided.
- Otherwise, the package statement in the .proto file, if present.
- Otherwise, the basename of the .proto file, without extension.
Gets whether the "cc_enable_arenas" field is set
Gets whether the "cc_generic_services" field is set
Gets whether the "csharp_namespace" field is set
Gets whether the "deprecated" field is set
Gets whether the "go_package" field is set
Gets whether the "java_generate_equals_and_hash" field is set
Gets whether the "java_generic_services" field is set
Gets whether the "java_multiple_files" field is set
Gets whether the "java_outer_classname" field is set
Gets whether the "java_package" field is set
Gets whether the "java_string_check_utf8" field is set
Gets whether the "objc_class_prefix" field is set
Gets whether the "optimize_for" field is set
Gets whether the "php_class_prefix" field is set
Gets whether the "php_metadata_namespace" field is set
Gets whether the "php_namespace" field is set
Gets whether the "py_generic_services" field is set
Gets whether the "ruby_package" field is set
Gets whether the "swift_prefix" field is set
This option does nothing.
If enabled, then the Java code generator will generate a separate .java
file for each top-level message, enum, and service defined in the .proto
file. Thus, these types will *not* be nested inside the wrapper class
named by java_outer_classname. However, the wrapper class will still be
generated to contain the file's getDescriptor() method as well as any
top-level extensions defined in the file.
Controls the name of the wrapper Java class generated for the .proto file.
That class will always contain the .proto file's getDescriptor() method as
well as any top-level extensions defined in the .proto file.
If java_multiple_files is disabled, then all the other classes from the
.proto file will be nested inside the single wrapper outer class.
Sets the Java package where classes generated from this .proto will be
placed. By default, the proto package is used, but this is often
inappropriate because proto packages do not normally start with backwards
domain names.
A proto2 file can set this to true to opt in to UTF-8 checking for Java,
which will throw an exception if invalid UTF-8 is parsed from the wire or
assigned to a string field.
TODO: clarify exactly what kinds of field types this option
applies to, and update these docs accordingly.
Proto3 files already perform these checks. Setting the option explicitly to
false has no effect: it cannot be used to opt proto3 files out of UTF-8
checks.
Sets the objective c class prefix which is prepended to all objective c
generated classes from this .proto. There is no default.
Sets the php class prefix which is prepended to all php generated classes
from this .proto. Default is empty.
Use this option to change the namespace of php generated metadata classes.
Default is empty. When this option is empty, the proto file name will be
used for determining the namespace.
Use this option to change the namespace of php generated classes. Default
is empty. When this option is empty, the package name will be used for
determining the namespace.
Use this option to change the package of ruby generated classes. Default
is empty. When this option is not set, the package name will be used for
determining the ruby package.
By default Swift generators will take the proto package and CamelCase it
replacing '.' with underscore and use that to prefix the types/symbols
defined. When this options is provided, they will use this value instead
to prefix the types/symbols defined.
The parser stores options it doesn't recognize here.
See the documentation for the "Options" section above.
public FileOptions()
Clears the value of the "cc_enable_arenas" field
Clears the value of the "cc_generic_services" field
Clears the value of the "csharp_namespace" field
Clears the value of the "deprecated" field
Clears the value of the "go_package" field
Clears the value of the "java_generate_equals_and_hash" field
Clears the value of the "java_generic_services" field
Clears the value of the "java_multiple_files" field
Clears the value of the "java_outer_classname" field
Clears the value of the "java_package" field
Clears the value of the "java_string_check_utf8" field
Clears the value of the "objc_class_prefix" field
Clears the value of the "optimize_for" field
Clears the value of the "php_class_prefix" field
Clears the value of the "php_metadata_namespace" field
Clears the value of the "php_namespace" field
Clears the value of the "py_generic_services" field
Clears the value of the "ruby_package" field
Clears the value of the "swift_prefix" field
public RepeatedField<TValue> GetOrInitializeExtension<TValue>(RepeatedExtension<FileOptions, TValue> extension)