Protocol Buffers - Google's data interchange format (grpc依赖) https://developers.google.com/protocol-buffers/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
csharptest 8a2d0f48d7 big-endian support for float, and double on Silverlight 14 years ago
benchmarks Benchmark data update. 16 years ago
build Slight refactoring of Extensions to support lookup by name, added compatibility tests for text and binary formats. 14 years ago
keys added batch for creating a new key 14 years ago
lib Added version command to PublishRelease.bat, added use of external signing key 14 years ago
mono Moved key file to /keys directory 14 years ago
protos Slight refactoring of Extensions to support lookup by name, added compatibility tests for text and binary formats. 14 years ago
src big-endian support for float, and double on Silverlight 14 years ago
testdata line-ending-to-crlf 14 years ago
.gitignore Completion of 3.5 build integration and Lite runtime build changes. 14 years ago
.hgignore version 2.3.0.277 14 years ago
license.txt Added license file 15 years ago
readme.txt Added license file 15 years ago
todo.txt line-ending-to-crlf 14 years ago

readme.txt

Welcome to the C# port of Google Protocol Buffers, written by Jon Skeet
(skeet@pobox.com) based on the work of many talented people.

For more information about this port, visit its homepage:
http://protobuf-csharp-port.googlecode.com

For more information about Protocol Buffers in general, visit the
project page for the C++, Java and Python project:
http://protobuf.googlecode.com


Release 0.9.1
-------------

Fix to release 0.9:

- Include protos in binary download
- Fix issue 10: incorrect encoding of packed fields when serialized
size wasn't fetched first


Release 0.9
-----------

Due to popular demand, I have built a version of the binaries to put
on the web site. Currently these are set at assembly version 0.9,
and an assembly file version of 0.9. This should be seen as a mark
of the readiness of the release process more than the stability of
the code. As far as I'm aware, the code itself is perfectly fine: I
certainly have plans for more features particularly around making
code generation simpler, but you should feel confident about the
parsing and serialization of messages produced with this version of
the library. Of course, if you do find any problems, *please* report
them at the web site.

Currently the downloadable release is built with the snk file which
is in the open source library. I am considering having a privately
held key so that you can check that you're building against a
"blessed" release - feedback on this (and any other aspect of the
release process) is very welcome.