minimize serialization code?
>
> On Monday, May 13, 2024 at 3:52:56 PM UTC+10 Marc Gravell wrote:
>
>> A tag isn't on a value - it is part of the *field header* which is the
>> combination of field-number and wire-type ; a fixed32 *value* is 32 bits.
>>
>> The size
A tag isn't on a value - it is part of the *field header* which is the
combination of field-number and wire-type ; a fixed32 *value* is 32 bits.
The sizes of values aren't directly controllable by you; protobuf-net isn't
a general purpose binary descriptor format and cannot usually be used to
impl
protobuf ensures that the *value of primitives* will be preserved; so if
you send the uint32 23433451, it will be decoded as 23433451 regardless of
the CPU/process endianness of sender and receiver. The details are
here: https://protobuf.dev/programming-guides/encoding/ - but they **don't
matt
If .NET is an option, protobuf-net has this (in the protobuf-net.Reflection
package):
var schema = """
syntax = "proto3";
package helloworld;
// My cool new message
message MyMessage {
string some_string = 1;
repeated int64 some_numbers = 2;
}
""";
var set = n
As long as you aren't using `Any`: then at the binary payload data it won't
be visible. Any existing code that uses the generated types will need to be
updated, obviously.
On Thu, 20 Apr 2023, 07:00 'Felik' via Protocol Buffers, <
protobuf@googlegroups.com> wrote:
> Hello,
>
> I came to understan
That is ... contextual, though; an unexpected sub-message can still,
depending on the implementation, be round-tripped and potentially even
inspected via reflection. It won't usually *break* code, just like adding
any new field. It really depends how strict you're being in you'd
definitions of comp
(oh, and not "map"; "map" is just a specialized example of the semantics
from "repeated", under the hood)
On Wed, 7 Dec 2022 at 10:11, Marc Gravell wrote:
> An 'optional' field is still singular (optional having been re-added to
> proto3 relatively
An 'optional' field is still singular (optional having been re-added to
proto3 relatively recently); singular just means: not 'repeated'
With regards to "wrappers.proto": all of the inner values in the wrapper
types are singular; as stated in the text part of wrappers.proto, it isn't
intended to u
For 1 options: a) don't assign a value to salary (unless it is "required"
in proto2, which doesn't appear to be the case), or b) create a new
EmployeeDataMinimal message that *doesn't have a salary*, and serialize that
(I can't comment on 2; not a C++ person)
On Mon, 28 Nov 2022 at 08:14, Lakshmi
No, protobuf does not have any resync capability. You're going to need to
wrap that yourself.
On Mon, 10 Oct 2022, 18:19 David L, wrote:
> When serializing a message with SerializeDelimitedToOstream, is the
> expectation that parsing the resulting serial stream will re-sync if some
> data is los
No
On Sat, 3 Sep 2022, 09:48 berge, wrote:
> Hi all!
>
> in C++(>=11) I can do:
> ```
> using TMyLittleType = int64_t;
>
> TMyLittleType xyz;
> ```
>
> Is there a trick I can use to do the same in proto3?
> like
> ```
> magictrick TMyLittleType = sint64;
>
> message XYZ
> {
>
>
Is this really a gRPC question? protobuf is just a payload serialization
format
If it *is* gRPC, then: *how* is the API key expected to be transmitted? Is
it a header? a payload item? Honestly, linking to the API specification
would be a good idea. Otherwise this is very vague.
On Wed, 15 Jun 202
Without a long-running process, what would this look like? what would cause
the remote / out-of-process execution?
On Thu, 5 May 2022 at 00:00, 'Bill Thorp' via Protocol Buffers <
protobuf@googlegroups.com> wrote:
> Inter-language interop is hard, but protocol buffers have good code
> generation
OK. To share data between platforms, you need two things:
1. A shared data layout
2. A shared serialization protocol
For 1: the inbuilt DataTable layout is implementation specific. There is no
shared (/common/agreed) shape that both .NET and Java both use, so: nothing
is readily available out of
You say "209 byte size" - using what measure is it 209 bytes? And what is
the data? The payload size in protobuf often depends on the specific data,
for example:
- for any fields: whether it is the default / unset value, vs whether it is
a non-detault / explicitly set value, can change whether the
I notice that the advisory is scant on details at the moment; is there any
mechanism for non-Google protobuf library authors to request additional
details to see whether our own implementations may be vulnerable to the
attack? Thanks
On Thu, 6 Jan 2022 at 17:15, 'Derek Perez' via Protocol Buffers
IIRC, the leading dot means that the name is absolute rather than relative.
I'm not sure it represents an error.
On Wed, 22 Dec 2021, 19:00 'Venkat Duddu' via Protocol Buffers, <
protobuf@googlegroups.com> wrote:
> We are seeing extra dot for external referenced variables in
> descriptorData in t
This is specific to protobuf-net. If you're using v3, the main usage here
is to provide explicit names for the enum and (via ProtoEnumAttribute) the
defined values; the names only matter if you are generating a .proto from a
code-first model (GetSchema(), GetProto(), etc)
In v2, you can *also* use
What language/framework?
On Wed, 5 May 2021, 09:58 Danny Lee, wrote:
> Hello everyone,
>
> There is a proto file as below.
> And it is required not to use the .options file.
>
> How to decode the data below:
> MsgInfo.data.msg2_data.data.msg22_data.jobs.job_data.job_attr.age
>
> Any useful sugge
The actual serialization format hasn't changed since protobuf was released;
as long as *your schemas* haven't changed in that time (at least, not in
incompatible ways; adding fields etc is pretty safe as long as they aren't
"required" in proto2), you should be absolutely fine. It is expected and
no
The tooling package you need here is Grpc.Tools, which should work fine in
a class library.
On Sun, 18 Apr 2021 at 23:08, Chris Langlois wrote:
> Thanks for the recommendations. I can add .proto files to the Shared
> projects. What I cannot do is add a build action for "protobuf compiler" to
> e
What is stopping you from adding them to the shared project? What TFM is it
targeting? This should JustWorkTM. You could also look at the csproj
changes in the client and server, and try to apply the same changes in the
shared project - it might tell you why it isn't happy.
On Sun, 18 Apr 2021, 19
I'm a little confused here...
Normally, assuming that this is using the Google implementation, you would
have, in your generated code:
- a generated concrete client proxy
- a generated abstract server stub
The client code would "new" the client proxy (the yellow code). Your server
code would dec
You can use protoc to output the compiled schema (one of the
command-line-options - something "file descriptor set"), and deserialize
the resultant binary file as a FileDescriptorSet instance, deserializing
via your choice of language via descriptor.proto - any use?
As an aside, I also have a sepa
Field number 76 with which wire type? The lowest 3 bits are the wire-type,
then the field number is whacked on the end. Then split into groups of 7
bits for varint encoding.
On Fri, 8 Jan 2021, 14:05 'emaz...@cisco.com' via Protocol Buffers, <
protobuf@googlegroups.com> wrote:
> Hi Marc,
>
> OK t
The composed wire-type and field number are treated as a varint. And since
the MSB is reserved for continuation, after the 3-bit wire type that only
leaves 4 bits of field number, not 5, for single-byte field headers.
On Fri, 8 Jan 2021, 12:47 'emaz...@cisco.com' via Protocol Buffers, <
protobuf@g
100 isn't "non-standard" as such, and shouldn't cause anything to fail.
What exactly are you seeing?
The valid range is 1-536870911, omitting 19000-1 (and any reserved
areas in your specific messages) smaller numbers are cheaper (fewer bytes)
to encode, so are usually preferred - but: that's i
"custom options" exist, but frankly they don't do much unless you have
custom code generation that is going to emit something useful from them,
and that "something" itself does something useful at runtime - which may
itself be tricky between runtimes/platforms.
Does "add a comment" suffice?
On We
Hi; it is pretty hard to comment without code. Do you have a minimal repro
that shows what you're seeing? The fact that you mention Encoding suggests
that you're treating protobuf data as though it were text, which is never a
good idea.
Also, since this is library specific, you may wish to move
See
https://developers.google.com/protocol-buffers/docs/overview#assigning_field_numbers
Basically:
- positive integers
- unique within each message (can reuse between different messages)
- lower is cheaper
- avoid some reserved ranges
On Tue, 30 Jun 2020, 20:12 rohit nv, wrote:
>
> I am new t
The google protobuf package (
https://www.nuget.org/packages/Google.Protobuf/) supports .NET 4.5 upwards;
protobuf-net (an independent / unaffiliated implementation of the
serializer) supports .NET 2.0 and upwards for v2.*, but: from v3.* onwards
that will change to .NET 4.6.1
Frankly, you are go
I would imagine that most implementations are still going to use field
number order. Is there a specific reason you need to control it? Most JSON
tools won't care, and if you want to control the JSON, frankly you
shouldn't be using an opinionated serializer like protobuf - you should be
using a sui
The most likely thing is that it was truncated during your transmission,
meaning: a bug in your code that serializes and/or sends the data. Can we
see any of that code? Note that you can use "protoc" (decode-raw) or
https://protogen.marcgravell.com/decode to validate a payload for integrity.
On Mo
Hi; default values *are not sent*, especially in proto3 where zero is
default and default is zero. Likewise, the root object in a message is not
wrapped in any way - only fields *on* the root object.
This means that the binary encoding of a CommandRequest with Code.RESET is:
zero bytes, which is a
The context here seems to be: "I have .proto file/files, and (for some
reason) I need to make additional tweaks to them in java/c#", right?
In the case of C#, "partial classes" may be your friend, especially if all
you are trying to do is add annotations/attributes. The tooling may also
generate "
That would prpbably be a great question for James NK over on the relevant
GitHub repo. IIRC the sample server includes reflection, though:
https://github.com/grpc/grpc-dotnet/
On Sat, 14 Dec 2019, 12:22 erik stroeken, wrote:
> Thanks Nadav Samet
> I've been trying to implement the concepts descr
Untested, but can't you just use protoc with the descriptor-set mode to
build a FileDescriptorSet (IIRC) which will be the processed output of
protoc's efforts? Then parse it using the details from descriptor.proto,
and see what descriptors are in the FileDescriptorSet?
--
You received this messa
Can you show what you mean by wrappers here? If you dump the payload and
inspect it (protoc, or there's a tool at
https://protogen.marcgravell.com/decode), is the data in the payload? A
minimal example, in some way, would really help
On Tue, 5 Nov 2019, 20:55 SW89, wrote:
> Good Afternoon,
>
> M
It just means "when serialized" i.e. when written into binary or JSON for
storage / transmission; the "wire format ordering" one is emphasizing that
maps have no defined order whether in-memory or serialized, and you should
not rely on the order in which elements appear when serialized - on disk /
c\source\repos\ConsoleApp14\Program.cs:line 16
On Wed, 21 Aug 2019 at 10:28, Arun wrote:
> I did the same but it throwing the error.. I dont know what I am making
> mistake here . All my application are 3.5 .net version,
>
> Please find actual CS file which I am trying to serialize.
&
thing other
>> than that it should work with the corresponding protobuf library.
>>
>> On Tue, 20 Aug 2019, 06:32 arun kumar, wrote:
>>
>>> @Marc Gravell,
>>>
>>> I auto-generated ".cs" files from each ".proto" file. . Wh
On Tue, 20 Aug 2019, 06:32 arun kumar, wrote:
> @Marc Gravell,
>
> I auto-generated ".cs" files from each ".proto" file. . Whereever a
> message declared inside another message in proto, auto-generated cs file is
> generated as " Nested Types " and Types
And can we see some code that actually demonstrates this problem? That
would really help here.
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsu
Protobuf binary or protobuf-flavored JSON.
On Thu, 18 Jul 2019, 08:35 Pratibha Pruno Xavier,
wrote:
> Hi all,
>
> What are the encoding formats supported by protobuf 3?
>
> THanks,
> Pratibha
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buff
That definition is simply adding metadata to the field definitions; they
won't directly impact protobuf if you're using the default tools, but if
you're using custom tools, or a layer on top of protobuf that knows how to
inspect metadata, it can do additional things with the information. The
metada
The "why" is because the marshaller assumes the root is a message; however,
you should look at "wrappers.proto" - there are well-known wrappers for
single values of most common types, including string. Also, prefer
"empty.proto" for empty, not your own.
On Sat, 29 Jun 2019 at 13:25, Ananya Bhat w
> On Sun, Jun 2, 2019 at 8:59 AM Marc Gravell
> wrote:
>
>> If it helps, protobuf-net's schema parser can do this. It is a slightly
>> different API to the Google implementation, though.
>>
>> You can test it online at https://protogen.marcgravell.com/ - o
If it helps, protobuf-net's schema parser can do this. It is a slightly
different API to the Google implementation, though.
You can test it online at https://protogen.marcgravell.com/ - or the
command-line tool is available as a standalone utility via various
mechanisms (the standalone command-lin
What exactly happens? Protocol buffers are designed to be forwards
compatible, so adding fields etc is usually fine and expected. Depending on
the implementation unexpected fields may be ignored or stored as extension
fields. So: is that what you did? And: what happened?
Note: changing the data ty
that just looks like `protoc` isn't in your path, and to be honest I
wouldn't really expect it to be; you'll need to either add it to your
system path list, or just use it from where-ever it installed
On Wed, 3 Apr 2019 at 16:20, abdelrahman hamdy <
hamdyabdelrahman...@gmail.com> wrote:
> I insta
= new MemoryStream(serializedObject))
> {
> return (T)Serializer.Deserialize(ms, null, typeof(T));
> }
> }
>
> Thanks much!
> Shweta
>
> On Wednesday, March 27, 2019 at 7:34:58 AM UTC-7, Marc Gravell wrote:
>>
>> &g
> using StackExchange.Redis MGET
Yeah, there's really no way for me to dodge this, is there? ;p
Minor note: your parallel code currently doesn't actually allow any
meaningful parallelism - you *might* want to move the "lock" so that you
only "lock" around the "Add". You're also currently doing a
Hi; I'd love to help you on this - I'm the protobuf-net author, and I also
know more than a little about redis; it *might* be a little off-piste for
this group though. Running some tests locally with 5000 instances, I get
times like 1ms, but it might be that I'm misunderstanding your object
model.
"bytes" is correct. The problem here is usually "treating binary data as
nul-terminated strings", which is almost certainly something *outside* of
the protobuf code, but in your code. Basically, you can't ever treat
protobuf data as nul-terminated strings.
On Wed, 23 Jan 2019, 00:52 What is the c
Presumably: convert the hex to bytes, and run it though the normal API for
your library/platform?
On Fri, 4 Jan 2019, 22:35 I have the java schema and the .proto schema for the data.
>
> The data is binary represented as hex. Is it possible to decode the data
> with the schemas I have? if so how?
without knowledge of the specific library/framework/language that you're
using, I doubt anyone can answer this.
On Tue, 18 Dec 2018 at 05:11, Ishaan Aggarwal
wrote:
> I have multiple .proto files in my project. I came to know that there can
> only be a single serializer and de-serializer file in
there's nothing wrong with those message definitions; you haven't told us
which platform and/or library you're using, but: my hunch would be that
you're transporting the data incorrectly in some way, meaning: corrupting
it in *your* code - or the code you're using to compress/decompress is
slightly
"set" isn't a protobuf concept - the closest that exists is "repeated";
likewise "object" - ideally using some defined message type. Putting those
together, that gives you:
syntax = "proto3";
message SomeRoot {
repeated SomeLeaf items = 1;
}
message SomeLeaf {
map values = 1;
}
message SomeVa
Are you talking about Java's Long here? If so, frankly I'd say: in your DTO
layer, use whatever type protoc wants to use for your data, and just use:
syntax = "proto3";
message TestMessage{
string attribute1 = 1;
map attribute2 = 2;
int64 attribute3 = 3;
int32 attribute4 = 4;
i
That's pretty vague. Could you clarify what you're trying to do?
On Wed, 12 Sep 2018, 09:00 qplc, wrote:
> Hi,
>
> How do I define wrapper Long value in .proto file. Can anyone help in this?
>
>
> Thanks,
> qplc
>
> --
> You received this message because you are subscribed to the Google Groups
>
You mention both 3.5 and 3.6 - which did you mean?
As for both compiling and links: it kinda depends what platform and/or
language you are targeting. So: what are you targeting? You'll usually have
to run the protoc output through your own build tools.
On Thu, 6 Sep 2018, 07:47 Natalia Duality,
I'm going to share some thoughts here simply for discussion purposes - I
don't expect them to be directly applicable.
FWIW, protobuf-net has spoofed inheritance for many many years. I'm able to
do this because protobuf-net only needs to target .NET, which has good
inheritance support.
I don't real
It is a little unclear what you mean, since the javascript Date constructor
itself takes the year first, but that is nothing to do with protobuf or
JSON, and nothing to do with the format.
If you mean the JSON, then:
In the JSON format, timestamp is always RFC 3339. In the binary format,
timesta
> I didn't see anything about lists though
See: "repeated"; this is pretty much a synonym for "list".
> Some items may reference other incoming packets.
No, there is no concept of an object id, whether for in-message or
out-of-message referencing.
On Sun, 29 Jul 2018 at 22:38, M P wrote:
>
ect?
>
> If the conversion to string is done, isn't the size of protobuf message
> going to be more compared to the case of using
> repeated uint32 localEndpoint = 1;
> ?
>
> Please let me know if I have confused you :) Thanks again!
>
> On Wednesday, July 18, 2018
> size of (encoded message
> using "int" type)
>
> Is my understanding correct? Thanks!
>
>
> On Wednesday, July 18, 2018 at 2:40:01 PM UTC+5:30, Marc Gravell wrote:
>>
>> At that point I'd probably use "repeated bytes", then. It'll c
sses
> -> OR 1 ipv4 + 1 ipv6 addresses
> in the field "localEndpoint".
>
> So in that case, is "oneof" usage correct? I think that a "oneof" cannot
> be repeated. Please correct me if I am wrong.
>
> On Wednesday, July 18, 2018 at 12:54:39 PM UTC
You should be able to encode ipv4 in 4 bytes, making fixed32 ideal, since
you can avoid the length prefix. For ipv6, you're going to need 16 bytes,
so "bytes" is probably your best bet, since it will only require a single
header. You can then create a union of those:
oneof ip_addr {
fi
Btw you might find https://protogen.marcgravell.com/decode useful - it
explains how each byte is interpreted. It doesn't give the details (so: it
doesn't explain how varint works), but it at least makes it explicit which
bytes have contributed to which outcomes.
On Tue, 17 Jul 2018,
AA 06 is indeed 101, that's "varint" encoding. The MSB of each byte is
continuation, 7 bits payload, and adjust for endianness. The idea of
decode-raw is that it is enough to start guessing at how to reverse
engineer a message, for example you can see values that are clearly string
IP-addresses. Ho
also, field zero (type) is invalid; you are welcome to use this as an
online check tool - but protoc also outputs similar messages:
https://protogen.marcgravell.com#gc4759103e204eec4ae1a11ce6089a4bf
On Thu, 12 Jul 2018 at 23:01, Marc Gravell wrote:
> datavalues_srarray and datavalues_prar
datavalues_srarray and datavalues_prarray need to have different field
numbers
On Thu, 12 Jul 2018 at 22:50, Himabindu Dittakavi
wrote:
> Hi All,
>
> New to protobuf.
> Here is my proto file. If i use the code highlighted in yellow it works
> but when I add the one in yellow - there is
I added a much longer version of this here:
https://stackoverflow.com/questions/50500626/what-is-the-relation-between-length-of-data-block-and-file-length-in-varint/50503626#50503626
On Thu, 24 May 2018 at 08:33, Marc Gravell wrote:
> I wonder if you're decoding it incorrectly. Mayb
I wonder if you're decoding it incorrectly. Maybe if you could post the
bytes that you're decoding to reach this contradictory result, we can
advise you.
On Thu, 24 May 2018 at 04:59, Ruman Ahmed Rizvi <
ruman.ahmed.rizvi@gmail.com> wrote:
> When working with protocol buffers and encoding and
It would probably help if you could be specific about what is happening
now. Have you got as far as running "protoc", or is the problem getting
"protoc" ready? If you have "protoc", what command are you using? Are there
error messages? If so: what do they say? Do you have an example .proto file?
N
(mainly for the list) see also the stackoverflow question:
https://stackoverflow.com/q/50387660/23354
On Thu, 17 May 2018 at 10:42, Alexey Vishnyakov
wrote:
> Hello
>
> We using protobuf v.3 to transfer messages from C# client to Java server
> over HTTP.
>
> The message proto looks like this:
>
anually checking that the bytes are valid.
>>
>> Tony, how are you framing the messages? Protocol buffers do not describe
>> their own size and so you have to know what size to expect before you parse
>> a proto. The typical approach is to frame the serialized messages by
>
upgrade protobuf and see if issue goes away. Just wanted to make sure
> I'm not missing anything. Is there any additional troubleshooting I can
> look into to troubleshoot further if the recent release reproduce the issue?
>
> On Tuesday, April 10, 2018 at 1:46:50 AM UTC-4, Mar
First thought: what language / platform is this? the C++ generated code is
very different to the Java generated code, for example
Second thought: 2.6 is pretty old; it is very possible that a bug existed
and has been fixed since then (Aug 2014) - does it still happen with more
recent releases?
Th
:07 am, "Som Shankar Bhattacharyya" <
bhattacharyya...@gmail.com> wrote:
> I see no remting format set. Looks like it used the default xml format.
>
> On Wed, Feb 14, 2018 at 12:11 AM, Marc Gravell
> wrote:
>
>> Protobuf doesn't touch security, so we can
Protobuf doesn't touch security, so we can ignore that one.
Modelling datasets/DataTable is awkward. It isn't really a natural fit, but
it can be manually forced. However, the first thing I'd say is: have you
set the "RemotingFormat" on the dataset to **binary** before using your
existing serializ
This is protobuf-net, so I suppose I should chime in :)
Can you please give a precise copy of the error message? And how did you
reference the library? Did you just add the NuGet package as normal? Or did
you do something more exotic? .NET libraries are almost usually distributed
as compiled assem
Protoc is available for multiple OSes here:
https://github.com/google/protobuf/releases/tag/v3.5.1
Note sure about pre-compiled libs; for Java, they're on mvnrepository; for
C# they're on NuGet, etc.
On 26 January 2018 at 15:22, 'Frank Willen' via Protocol Buffers <
protobuf@googlegroups.com> wro
Yes, tags (field numbers) can be non-contiguous.
Yes, hex is accepted by protoc
No, repeated fields cannot be required
On 22 January 2018 at 23:08, Ashwin Kini wrote:
> Hi all,
>
> While defining messages can the *tags *be non continous? The
> documentation never mentions the same
>
> message
I did a test locally using protobuf-net (since that is what I'm most
familiar with); to get an output of about 3,784,000 I used a count of
172000 items in the inner array - does that sound about right? Then I
tested it in a loop as per this gist: https://gist.github.com/mgravell/
10a219705314850087
a zero tag is never valid in any protobuf data, although it wouldn't be
unheard of for folks to use a zero tag as a sentinel value to demark
multiple root messages. Protoc has some facilities to check the insides of
a message that might help you figure out how likely it is to be a match,
but it won
is a
> series of top-level parameters. So, I have to give it the Parameter I’m
> looking for. The problem I have with this is the order of parameters
> _might_ matter, and I lose that by only looking for one.
>
> On Dec 10, 2017, at 8:35 AM, Marc Gravell wrote:
>
> as I ubd
uot; message is. It
> seems like an omission in the whole PB thing that you can't specify the
> .proto and do a --decode_everything.
>
> On Sunday, December 10, 2017 at 8:23:12 AM UTC-8, Marc Gravell wrote:
>>
>> You can and it does. The problem is that the wire format by
They are field numbers. They don't mean anything by themselves other than
to identify each field. If you want to know the logical *name* of each
field, you need the .proto schema.
On 10 Dec 2017 4:23 p.m., "Jim Baldwin" wrote:
> Perhaps it might help if I understood the output of protoc --decode
You can and it does. The problem is that the wire format by itself doesn't
tell it **what message type** the root object is. So you need to tell it in
the additional parameter to --decode
On 10 Dec 2017 3:14 p.m., "Jim Baldwin" wrote:
It's not really just a sequence; it's a hierarchy, isn't it?
esentation, since string
> fields are for UTF-8 only. We could consider eventually creating a
> well-known type but I'm not sure how much demand there is for one.
>
> On Wed, Dec 6, 2017 at 11:46 AM, Marc Gravell
> wrote:
>
>> A question on Stack Overflow earlier (http
Apparently https://github.com/square/wire/ includes a runtime .proto parser
for Java. That might help? It isn't the official one, note.
On 6 Dec 2017 8:28 p.m., "Omar Al-Safi" wrote:
> Hello folks,
>
> I stubbled upon a requirements that I receive a textual representation of
> a proto file from
A question on Stack Overflow earlier (
https://stackoverflow.com/questions/47674930/google-protobuf-proto-file-query/4767629)
reminded me that I'm not fully "up" on the conventions for using guids in
protobuf.
There's no primitive / keyword for them, and AFAIK no "well known type". So
: how do fol
Not really, no. They take different amounts of space on the wire, and have
a different declared wire type (header). Some libraries may choose to be
gracious and apply the conversion silently, but other libraries could just
say "unexpected wire type" and stop processing.
You could perhaps do it as
requested claritication and *possibly* answered here:
https://stackoverflow.com/questions/47246474/protobuf-how-to-combine-fieldoptions-with-default-values-in-messages
On 12 Nov 2017 7:12 a.m., wrote:
> I have an message using FieldOptions but I also want to use default values
> as well, how do
protobuf-net should work with proto 2 - try here:
https://protogen.marcgravell.com
On 27 Oct 2017 6:16 p.m., "cleal" wrote:
> I have to integrate a third part protocol from a gps device, they send me
> the .proto files, they are using the schema proto2.
>
> I should receive the binary messages a
lines of query
> results. It works fine, but I'm stuck on how to display the results on an
> aspx page. Any idea please?
>
>
> Le jeudi 27 mai 2010 09:30:03 UTC+3, Marc Gravell a écrit :
>
>> With "full" .NET to .NET WCF, then switching the serialization la
ctober 2017 at 09:48, Marc Gravell wrote:
> Yes, something like that; example: https://pastebin.com/CUvWz00L
>
> On 23 October 2017 at 09:38, Nihar Mishra wrote:
>
>> Hi Marc,
>> Thanks a lot. Yes this is protobuf-net.
>> Still i don't get how to modify AttributeV
bers for the 4 types?
>
> best Regards,
> Nihar
>
>
> On Mon, Oct 23, 2017 at 9:19 AM, Marc Gravell
> wrote:
>
>> I'm assuming this is protobuf-net; the message is right : the library
>> can't work with "object itemField". Perhaps the best
I'm assuming this is protobuf-net; the message is right : the library
can't work with "object itemField". Perhaps the best thing would be to
treat this like a "oneof" (in .proto terms) and have an accessor per
possible type. For example:
[ProtoMember(n)]
private int ValueInt32 {
g
1 - 100 of 398 matches
Mail list logo