my rage from v8 is spilling over
Go to file
2010-05-19 21:15:10 +01:00
benchmarks Benchmark data update. 2009-03-05 23:28:32 +00:00
lib Added a flag to allow code contracts to be emitted 2009-11-03 17:36:32 +00:00
mono Mono build file improvements and readme 2009-06-25 20:31:26 +01:00
protos Allow creation of namespace directories 2010-02-08 11:28:57 +00:00
src Fix issue 10 - check serialized size before writing to stream 2010-05-19 21:07:58 +01:00
testdata Commit earlier deletes 2009-03-05 13:22:15 +00:00
.gitignore Ignore mono binaries 2009-09-09 10:08:42 +01:00
ProtocolBuffers.build Fixed build to work with VS2010 2010-05-19 21:15:10 +01:00
readme.txt Release preparation 2010-04-01 20:32:45 +01:00
todo.txt Better support for Compact Framework builds 2010-02-08 11:06:54 +00:00

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
-----------

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.