aboutsummaryrefslogtreecommitdiffhomepage
path: root/csharp/src/Google.Protobuf/Reflection/MessageDescriptor.cs
Commit message (Collapse)AuthorAge
* Remove the executable bit from several source code filesGravatar Sebastian Schuberth2018-06-25
| | | | This potentially avoids compiler warnings.
* Fixes for .NET 3.5 compatibilityGravatar John Brock2017-02-23
| | | | | * Changing DOTNET35 framework symbols in preprocessor directives to the default built-in value of NET35. * Adding extension method StreamExtension.CopyTo for .NET 3.5 because it didn’t exist until .NET 4, and adding associated unit tests.
* Support custom options in C#Gravatar Jon Skeet2017-01-19
| | | | | | | | | | | | This consists of: - Changing the codegen for the fixed set of options protos, to parse unknown fields instead of skipping them - Add a new CustomOptions type in the C# support library - Expose CustomOptions properties from the immutable proto wrappers in the support library Only single-value options are currently supported, and fetching options values requires getting the type right and knowing the field number. Both of these can be addressed at a later time. Fixes #2143, at least as a first pass.
* Adding conditional compiler symbol to support .NET 3.5 (#1713)Gravatar detlevschwabe2016-06-28
| | | | * Adding condition compiler symbol to support .NET 3.5
* Code review fixesGravatar alien2016-03-29
|
* csharp: add support for the json_name optionGravatar alien2016-03-18
| | | | | Conflicts: csharp/src/Google.Protobuf/JsonFormatter.cs
* Rename GeneratedCodeInfo to GeneratedClrTypeInfoGravatar Jon Skeet2016-02-04
| | | | | | | Recently, descriptor.proto gained a GeneratedCodeInfo message, which means the generated code conflicts with our type. Unfortunately this affects codegen as well, although this is a part of the public API which is very unlikely to affect hand-written code. Generated code changes in next commit.
* Allow the original field name (rather than camel-cased) when parsing JSONGravatar Jon Skeet2016-01-15
|
* Generated code changes for previous commit (basically ↵Gravatar Jon Skeet2015-11-22
| | | | InternalBuildGeneratedFileFrom => FromGeneratedCode)
* Tidy up reflection in advance of attempting to implement DynamicMessage.Gravatar Jon Skeet2015-11-22
| | | | | | | | | There are corner cases where MessageDescriptor.{ClrType,Parser} will return null, and these are now documented. However, normally they *should* be implemented, even for descriptors of for dynamic messages. Ditto FieldDescriptor.Accessor. We'll still need a fair amount of work to implement dynamic messages, but this change means that the public API will be remain intact. Additionally, this change starts making use of C# 6 features in the files that it touches. This is far from exhaustive, and later PRs will have more. Generated code changes coming in the next commit.
* Introduce a Parser property into MessageDescriptor, and populate it from ↵Gravatar Jon Skeet2015-11-19
| | | | | | generated types. Generated code coming in next commit - in a subsequent PR I want to do a bit of renaming and redocumenting around this, in anticipation of DynamicMessage.
* Move the creation of the "fields by JSON name" dictionary to the descriptor.Gravatar Jon Skeet2015-11-04
|
* Document everything, and turn on errors if we fail to document anything in ↵Gravatar Jon Skeet2015-08-04
| | | | the future.
* Fix trivial bug in field orderings.Gravatar Jon Skeet2015-07-31
| | | | (Shows the benefit of unit testing even code "too simple to fail"...)
* Implemented Jan's suggestion of FieldCollection, replacing ↵Gravatar Jon Skeet2015-07-22
| | | | | | | | | | FieldAccessorCollection. I think Jan was actually suggesting keeping both, but that feels redundant to me. The test diff is misleading here IMO, because I wouldn't expect real code using reflection to use several accessors one after another like this, unless it was within a loop. Evidence to the contrary would be welcome :) This change also incidentally goes part way to fixing the issue of the JSON formatter not writing out the fields in field number order - with this change, it does except for oneofs, which we can fix in a follow-up change. I haven't actually added a test with a message with fields deliberately out of order - I'm happy to do so though. It feels like it would make sense to be in google/src/protobuf, but it's not entirely clear what the rules of engagement are for adding new messages there. (unittest_proto3.proto?)
* Added newlinesGravatar Jon Skeet2015-07-22
|
* First pass at making field access simpler.Gravatar Jon Skeet2015-07-22
| | | | This is definitely not ready to ship - I'm "troubled" by the disconnect between a list of fields in declaration order, and a mapping of field accessors by field number/name. Discussion required, but I find that easier when we've got code to look at :)
* Remove the usage of attributes for field/method discovery.Gravatar Jon Skeet2015-07-22
| | | | Instead, introduce GeneratedCodeInfo which passes in what we need, and adjust the codegen to take account of this.
* Revamp to reflection.Gravatar Jon Skeet2015-07-21
| | | | | | | | | | | | | | | | | Changes in brief: 1. Descriptor is now the entry point for all reflection. 2. IReflectedMessage has gone; there's now a Descriptor property in IMessage, which is explicitly implemented (due to the static property). 3. FieldAccessorTable has gone away 4. IFieldAccessor and OneofFieldAccessor still exist; we *could* put the functionality straight into FieldDescriptor and OneofDescriptor... I'm unsure about that. 5. There's a temporary property MessageDescriptor.FieldAccessorsByFieldNumber to make the test changes small - we probably want this to go away 6. Discovery for delegates is now via attributes applied to properties and the Clear method of a oneof I'm happy with 1-3. 4 I'm unsure about - feedback welcome. 5 will go away 6 I'm unsure about, both in design and implementation. Should we have a ProtobufMessageAttribute too? Should we find all the relevant attributes in MessageDescriptor and pass them down, to avoid an O(N^2) scenario? Generated code changes coming in the next commit.
* First part of JSON formatting for well-known types. I think we need a ↵Gravatar Jon Skeet2015-07-20
| | | | reflection API rethink before doing the rest.
* First pass at the big rename from ProtocolBuffers to Google.Protobuf.Gravatar Jon Skeet2015-07-17
We'll see what I've missed when CI fails...