aboutsummaryrefslogtreecommitdiff
path: root/csharp/src/Google.Protobuf/Google.Protobuf.csproj
Commit message (Collapse)AuthorAgeFilesLines
* Use checked-in key to build ReleaseSignedJan Tattermusch2016-02-091-1/+1
|
* Rename Preconditions to ProtoPreconditionsJon Skeet2016-02-041-1/+1
| | | | (Generated code changes in next commit.)
* Rename GeneratedCodeInfo to GeneratedClrTypeInfoJon Skeet2016-02-041-1/+1
| | | | | | | 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.
* Ensure that FieldMask, Timestamp and Duration ToString() calls don't throwJon Skeet2016-01-201-0/+1
| | | | | | | | | | | | | The usage of ICustomDiagnosticMessage here is non-essential - ToDiagnosticString doesn't actually get called by ToString() in this case, due to JsonFormatter code. It was intended to make it clearer that it *did* have a custom format... but then arguably I should do the same for Value, Struct, Any etc. Moving some of the code out of JsonFormatter and into Duration/Timestamp/FieldMask likewise feels somewhat nice, somewhat nasty... basically there are JSON-specific bits of formatting, but also domain-specific bits of computation. <sigh> Thoughts welcome.
* Introduce ICustomDiagnosticMessage to allow for custom string formattingJon Skeet2016-01-131-0/+1
| | | | This fixes issue #933, effectively.
* add reference generator dependencyJan Tattermusch2015-12-171-0/+10
|
* Added the type registry in advance of implementing Any support.Jon Skeet2015-11-211-0/+1
| | | | Biting off just this bit first as I don't need the changes from a previous PR for this part.
* Generated code changes and manual changes for previous commit.Jon Skeet2015-11-091-1/+1
|
* Created a new exception for JSON failures.Jon Skeet2015-11-051-0/+1
| | | | | | This is only thrown directly by JsonTokenizer, but surfaces from JsonParser as well. I've added doc comments to hopefully make everything clear. The exception is actually thrown by the reader within JsonTokenizer, in anticipation of keeping track of the location within the document, but that change is not within this PR.
* Implement JSON parsing in C#.Jon Skeet2015-11-031-0/+5
| | | | | | | | | | This includes all the well-known types except Any. Some aspects are likely to require further work when the details of the JSON parsing expectations are hammered out in more detail. Some of these have "ignored" tests already. Note that the choice *not* to use Json.NET was made for two reasons: - Going from 0 dependencies to 1 dependency is a big hit, and there's not much benefit here - Json.NET parses more leniently than we'd want; accommodating that would be nearly as much work as writing the tokenizer This only really affects the JsonTokenizer, which could be replaced by Json.NET. The JsonParser code would be about the same length with Json.NET... but I wouldn't be as confident in it.
* Pack/Unpack implementation for Any.Jon Skeet2015-09-041-0/+1
| | | | | We still need the JSON representation, which relies on something like a DescriptorPool to fetch message types from based on the type URL. That will come a bit later. (The DescriptorPool comment in this commit is just a note which will prove useful if we use DescriptorPool itself.)
* More TODOs done.Jon Skeet2015-08-101-0/+1
| | | | | | - Removed a TODO without change in DescriptorPool.LookupSymbol - the TODOs were around performance, and this is only used during descriptor initialization - Make the CodedInputStream limits read-only, adding a static factory method for the rare cases when this is useful - Extracted IDeepCloneable into its own file.
* Document everything, and turn on errors if we fail to document anything in ↵Jon Skeet2015-08-041-3/+9
| | | | the future.
* make changes and fixes in signingJan Tattermusch2015-08-021-5/+3
|
* build signed assembliesJan Tattermusch2015-08-021-0/+15
|
* Well-known type operations for Timestamp and Duration (but not JSON formatting).Jon Skeet2015-07-311-0/+3
| | | | | While I've provided operators, I haven't yet provided the method equivalents. It's not clear to me that they're actually a good idea, while we're really targeting C# developers who definitely *can* use the user-defined operators.
* Rename ThrowHelper to Preconditions and make it public - we'll want to use ↵Jon Skeet2015-07-301-1/+1
| | | | | | | it from the generated code soon. Additionally, change it to return the value passed, and make it generic with a class constraint. A separate method doesn't have the class constraint, for more unusual scenarios.
* remove the freeze APIJan Tattermusch2015-07-291-1/+0
|
* First attempt at using profile 259 for Google.Protobuf.Jon Skeet2015-07-271-2/+5
| | | | | | | | This requires .NET 4.5, and there are a few compatibility changes required around reflection. Creating a PR from this to see how our CI systems handle it. Will want to add more documentation, validation and probably tests before merging. This is in aid of issue #590.
* Remove the usage of attributes for field/method discovery.Jon Skeet2015-07-221-2/+1
| | | | Instead, introduce GeneratedCodeInfo which passes in what we need, and adjust the codegen to take account of this.
* Revamp to reflection.Jon Skeet2015-07-211-1/+2
| | | | | | | | | | | | | | | | | 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 pass at the big rename from ProtocolBuffers to Google.Protobuf.Jon Skeet2015-07-171-0/+122
We'll see what I've missed when CI fails...
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-03 11:15:19 +0000