has_ functions missing in protobuf-net?

[GoogleCodeExporter]

We use protocol buffers for communication between native C++ apps, but also 
between native C++ app and .NET application (all is VS2012)
We rely in C++ heavily on the has_ functions that are available for an optional 
element. 

E.g. if we have a message with a field optional bool, it can be that it is not 
set, it is set to true, or it is set to false.

In C++ this can be checked with the function has_field and if set then the 
content can be fetched with get_field function. If not set, and get_field is 
called, then the get returns the default, which if not explicitly set is false.

This works perfectly in C++, but, in .NET however, we cannot seem to find the 
equivalent of the has_ function, and, when the message is received, the field 
is added to the message and it's content is set to the default, being false. 
It's not a disaster that the field is there with the default, but the problem 
is that there is no has_ function.

Please advise whether this is a bug or whether we missed something in 
protobuf-net and that this actually is possible 

Thx in advance.
Wim
For more info or discussion, mail to wim dot van dot houts at voxtron dot com

Please include an e-mail address if this might need a dialogue!
==============

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by WVHInfor...@gmail.com on 19 Sep 2013 at 7:45

[GoogleCodeExporter]

If you are generating from a .proto schema with protogen, by *default* 
protobuf-net just gives the raw values; however, you can use the 
`detectMissing` switch , which will cause the code-gen to add `*Specified` 
properties and `ShouldSerialize*` methods (these are standard .NET naming 
conventions used by and recognised by several framework classes). The 
`*Specified` operates like `has_*`. IIRC, `/p:detectMissing` at the 
command-line should enable that.

Original comment by marc.gravell on 19 Sep 2013 at 8:56

[GoogleCodeExporter]

Hi,

ok, i added the detectMissing switch to the command and now it indeed generates 
the *Specified functions. Still, compilation does not work and it is for a very 
"funny" reason. One of our fields is named "value", and, the generator does not 
complain on this, but, the compiler does because in the set{} and get{} 
functions that it generates, value is C# keyword. For boolean proprties it does 
not even complain, but then value is not necesarilly connect. For int and other 
properties, it complains about type mismatches, because it mistakes the keyword 
"value" with the field named "value" (luckily we detected it that way, because 
with booleans only we would not have found out)

In C++ this of course does not give any issues since value is not a keyword, 
and value is also not a predefined keyword in the protocol buffer definition if 
I'm not mistaken. Of course, "simple" solution would be to rename the field, 
or, do you think that everything that is possible in protocol buffers should be 
possible in protobuf-net, and thus in this case, a fix has to be made to 
protobuf-net to enable this?

Kind regards, and thx already for the extremely fast response !!

Wim

private byte[] _value;

 [global::ProtoBuf.ProtoMember(2, IsRequired = false, Name=@"value", DataFormat = global::ProtoBuf.DataFormat.Default)]

 public byte[] value

{

 get { return _value?? null; }

 set { _value = value; }

}

 [global::System.Xml.Serialization.XmlIgnore]

 [global::System.ComponentModel.Browsable(false)]

 public bool valueSpecified

{

 get { return _value != null; }

 set { if (value == (_value== null)) _value = value ? value : (byte[])null; } //--> Compiler fails here, value is keyword, but also byte[] field from the message

}

 private bool ShouldSerializevalue() { return valueSpecified; }

 private void Resetvalue() { valueSpecified = false; }

Original comment by WVHInfor...@gmail.com on 19 Sep 2013 at 9:40

[GoogleCodeExporter]

Yes, that is a bug; fixed in r667 - you can just take the csharp.xslt from here 
(https://protobuf-net.googlecode.com/svn/trunk/ProtoGen/csharp.xslt) and copy 
it over the one in your protogen.exe folder - it will pick it up from there

Original comment by marc.gravell on 19 Sep 2013 at 10:08

• Changed state: Fixed

[GoogleCodeExporter]

Ok, thx again for the swift response and solution. 

Original comment by WVHInfor...@gmail.com on 19 Sep 2013 at 10:58