ebceu4 / protobuf-csharp-port Goto Github PK

0.0 0.0 0.0 0 B

Automatically exported from code.google.com/p/protobuf-csharp-port

protobuf-csharp-port's People

Watchers

protobuf-csharp-port's Issues

Implicit conversions of protos with one member

I sometimes create protos with only one member, to get better type-safety.
For instance it's somewhat safer when a method getNode has signature
getNode(NodeID id) than getNode(int id), because in the later case your
risk passing some completely arbitary int to the method.

The problem with this approach however is that the type conversions are a
bit cumbersome. It would therefore be really cool if protos which only have
one member could implement implicit type conversion to the type of it's
member.

Original issue reported on code.google.com by carl%[email protected] on 1 Nov 2009 at 8:14

Add support for Code Contracts

Thanks for a great port of PB! 

Yesterday I started playing around with Code Contracts in Visual Studio 
and I noticed that the static analyzer outputs quite a lot of warnings 
about the generated protos. It would be great if you could either add the 
option to suppress static analysis of the protos (through 
[ContractVerification(false)]) or add the contract conditions required to 
stop Visual Studio from outputting the warnings. I understand that this 
would break backward compatibility but maybe you can add it as an option? 

Adding [ContractVerification(false)] to the classes can probably be 
implemented in conjunction with Issue #3.

Original issue reported on code.google.com by carl%[email protected] on 29 Oct 2009 at 3:33

Support for using Json/Xml formats with ICodedInputStream

What steps will reproduce the problem?

Currently the format input readers for xml and json do not allow manually 
reading the start of the root object.  Due to this, you can not keep the format 
hidden from the method/object reading the message.

This comes into play when using the IRpcServerStub's CallMethod API, as well as 
other places.


Required additions:

Both of these readers need the ability to explicitly read the root object 
preamble.  In addition it would be nice to have writers also implement this 
behavior for the same reasons.

Original issue reported on code.google.com by [email protected] on 9 Sep 2011 at 1:01

Reusable Builder classes

As per Java 2.4.0:

  * Builders now maintain sub-builders for sub-messages. Use getFooBuilder()
    to get the builder for the sub-message "foo". This allows you to
    repeatedly modify deeply-nested sub-messages without rebuilding them.

  * Builder.build() no longer invalidates the Builder for generated messages
    (You may continue to modify it and then build another message).

Original issue reported on code.google.com by [email protected] on 19 Aug 2011 at 3:46

Message with Field same name as message causes uncompilable .cs

Sample proto:

  package Test;

  import "google/protobuf/csharp_options.proto";

  option (google.protobuf.csharp_file_options).namespace = "Test";
  option (google.protobuf.csharp_file_options).umbrella_classname = "TestContainer";

  option optimize_for = SPEED;

  message A {
     optional int32 _A = 1;
  }

This is supported in the Java version, so we should really try to make it work.

Original issue reported on code.google.com by jonathan.skeet on 5 Apr 2011 at 4:10

Find an alternative answer for extension methods introduced in Google.ProtocolBuffers.Serialization assembly

The means used to add extension methods in the 
Google.ProtocolBuffers.Serialization assembly needs to be reconsidered.

*Current Approach*
Currently this is done by adding a faux "System.Core.dll" assembly that can be 
referenced by a 2.0 framework project.  The assembly contains nothing more than 
the required attribute to make this work.  This assembly is never shipped, nor 
copied to an output directory, it just allows the use of extension methods.  
It's a 2.0 "hack" that doesn't break compatibility with using the same assembly 
in 3.5 as adding the attribute to a different assembly would (like LinkBridge 
does).  The other benefit to this approach is that if anyone retargets the 
assembly at 3.5 or later the "real" "System.Core" will be used. 

*Issues*
This means we've got a reference within the assembly to an attribute which 
can't be resolved at execution time. It feels like the kind of thing which 
certainly could cause a problem if anything decides to resolve assembly 
references - which has certainly been known.

*Solutions?*
How about having separate configurations for this - .NET 2.0 and .NET 3.5 - and 
only conditionally compiling the "this"? I feel your pain - it would be so nice 
if extension methods were okay on 2.0, but it just feels like a risk too far 
for a relatively small benefit.

Original issue reported on code.google.com by [email protected] on 30 Sep 2011 at 12:48

Building the AddressBookProto.cs file in \Release\v4.0 does not work with AddressBook example project

As requested in the stackoverflow question...

http://stackoverflow.com/questions/11966135/rebuilding-the-addressbook-example-i
n-protobuf-csharp-port-2-4-1-473?wwparam=1345067821

I am trying to regenerate AddressBookProtos.cs using the files from 
protobuf-csharp-port-2.4.1.473-release-binaries.

What steps will reproduce the problem?
1. ----------------------------------------------------------------

C:\Work\Protocol 
Buffers\protobuf-csharp-port-2.4.1.473-release-binaries\Release\v4.0>copy 
..\..\protos\tutorial\addressbook.proto .
        1 file(s) copied.

C:\Work\Protocol 
Buffers\protobuf-csharp-port-2.4.1.473-release-binaries\Release\v4.0>copy 
..\..\protos\google\protobuf\csharp_options.proto .
        1 file(s) copied.

C:\Work\Protocol 
Buffers\protobuf-csharp-port-2.4.1.473-release-binaries\Release\v4.0>copy 
..\..\protos\google\protobuf\descriptor.proto .
        1 file(s) copied.

C:\Work\Protocol 
Buffers\protobuf-csharp-port-2.4.1.473-release-binaries\Release\v4.0>copy 
..\..\protoc\protoc.exe .
        1 file(s) copied.

2. -----------------------------------------------------------------
In \v4.0, added the following lines to addressbook.proto below 'package 
tutorial':
import "csharp_options.proto";

option (google.protobuf.csharp_file_options).namespace = 
"Google.ProtocolBuffers.Examples.AddressBook";
option (google.protobuf.csharp_file_options).umbrella_classname = 
"AddressBookProtos"; 

3. -----------------------------------------------------------------
In \v4.0, changed the following line in csharp_options.proto from:
import "google/protobuf/descriptor.proto";
to
import "descriptor.proto";

4. -----------------------------------------------------------------
C:\Work\Protocol 
Buffers\protobuf-csharp-port-2.4.1.473-release-binaries\Release\v4.0>ProtoGen.ex
e .\addressbook.proto .\csharp_options.proto .\descriptor.proto
 --proto_path=.

5. -----------------------------------------------------------------
Copied the generated AddressBookProtos.cs to C:\Work\Protocol 
Buffers\protobuf-csharp-port-2.4.1.473-source\protobuf-csharp-port-2.4.1.473-sou
rce\src\AddressBook

6. -----------------------------------------------------------------
Built AddressBook.exe using the new AddressBookProtos.cs file.

What is the expected output? What do you see instead?
As per the stack overflow article.

What version of the product are you using? On what operating system?
protobuf-csharp-port-v2.4.1.473, Windows 7 Enterprise 64bit SP1, VS2010 
10.0.40219.1 SP1Rel and .Net 4.0.30319 SP1Rel

Please provide any additional information below.
If I run protogen.exe from C:\Work\Protocol 
Buffers\protobuf-csharp-port-2.4.1.473-release-binaries\Protoc and only do the 
following modifications to AddressBook.proto:

import "google/protobuf/csharp_options.proto";
option (google.protobuf.csharp_file_options).namespace = 
"Google.ProtocolBuffers.Examples.AddressBook";
option (google.protobuf.csharp_file_options).umbrella_classname = 
"AddressBookProtos";

Then the generated AddressBookProtos.cs file works. What is the 
purpose\difference between the files in \Release and \Protoc?

Original issue reported on code.google.com by [email protected] on 16 Aug 2012 at 12:39

Default value problem

What steps will reproduce the problem?
1. Create and compile protofile with field with default value. E.g. "required 
uint32 somefield = 1 [default = 0]" by protoc and protogen.
2. Create message in C++ program, but don't set somefield.
3. Serialize it to array and send to C# program.
4. Deserialize from array in C# program.

What is the expected output? What do you see instead?
Deserialized message. But I see exception "Message missing required fields: 
somefield".

What version of the product are you using? On what operating system?
protobuf-csharp-port-2.4.1. Windows 7.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 23 Apr 2012 at 12:31

Specialized transcoding to/from Json for specific types

I have a custom DateTimeProto and GuidProto classes that are binary structures 
which is great for talking to an embedded device running protocol buffers in 
C++.

On the C# side, I use the same protocol buffer messages and output Json to a 
web service.  For those specific types, I would like to input/output specific 
strings in standard string formats instead of a structure.

For example, instead Json like 
"CreateDate": {
    "year": 2009,
    "month": 2,
    "day": 11,
    "hour": 10,
    "minute": 35,
    "second": 19,
    "millisecond": 510,
    "kind": "UNSPECIFIED"
}

I want something that jscript libraries can understand (rfc3339) and is compact:
CreateDate : "2009-02-11T10:35:19.510-00:00"

The same for GUID, input/output a string on the Json side and binary numbers on 
the protocol buffers side.  The reason is that a formatted string in Json is 
much more compact and readable than in the structure format.

I have been looking at subclassing JsonFormatReader and JsonFormatWriter to 
implement exceptions for my specific cases.  I'm not sure if this is the 
correct approach or not.  It looks pretty abstract and changing it for such a 
specific case would not be very reusable.

Another option would be to have a "custom format" interface and then add that 
as a partial to the generated DateTimeProto and GuidProto and then skip the 
reading and writing of all the fields and use the interface functions to 
directly handle the serialization and deserialization to/from Json for those 
objects.

Any thoughts?

Original issue reported on code.google.com by [email protected] on 15 May 2012 at 5:24

Code review for issue 16

Purpose of code changes on this branch:
http://code.google.com/p/protobuf-csharp-port/issues/detail?id=16

When reviewing my code changes, please focus on:

http://code.google.com/p/protobuf-csharp-port/source/diff?spec=svn53f0c2239fa0ef
d5bd974291eba29c5e3a71d10d&old=issue-16&r=778f62c330ce41cfdda0383fa9907b363e34bc
69&format=unidiff&path=%2Fsrc%2FProtoGen%2FUmbrellaClassGenerator.cs

branch:
http://code.google.com/p/protobuf-csharp-port/source/list?name=issue-16

After the review, I'll merge this branch into:
/default

Original issue reported on code.google.com by [email protected] on 13 Aug 2011 at 1:24

import doesn't work

What steps will reproduce the problem?
1. Create two proto files: first.proto, second.proto.
2. Add import "first.proto" 
3. Run ProtoGen.exe second.proto.

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

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

Original issue reported on code.google.com by [email protected] on 16 Apr 2012 at 2:30

Remove usages of SortedList`2 for SILVERLIGHT2 builds

Seems our silverlight assembly may be flawed.  After adding a SILVERLIGHT2 
build of Google.ProtocolBuffers.Serialization and depending upon 
Google.ProtocolBuffers an error is raised that says SortedList`2 can not be 
found in system.dll.

Sure enough, SortedList`2 is not supported by SILVERLIGHT2.

Original issue reported on code.google.com by [email protected] on 1 Oct 2011 at 3:31

Is Silverlight generated code identical to regular C# generated code?

The documentation doesn't mention Silverlight support, however the code seems 
to have support for Silverlight (as does 
http://code.google.com/p/protobuf-csharp-port/source/detail?r=54)

I would like to know if the only difference for Silverlight is in 
Google.ProtocolBuffers.dll, or do I have to generate two sets of *.cs source 
files for my *.proto files - one for my C# server and one for my Silverlight 
client.

Original issue reported on code.google.com by [email protected] on 26 Dec 2010 at 1:38

IRpcController isCanceled should be either IsCanceled or be a property

The IRpcController isCanceled is Java-style named, should be IsCanceled() 
or even a property.

Original issue reported on code.google.com by [email protected] on 8 Nov 2009 at 9:13

Code review for issue 13

Purpose of code changes on this branch:
http://code.google.com/p/protobuf-csharp-port/issues/detail?id=13

When reviewing my code changes, please focus on:

Commits to branch 'issue-13'
http://code.google.com/p/protobuf-csharp-port/source/list?name=issue-13

After the review, I'll merge this branch into:
/default

Original issue reported on code.google.com by [email protected] on 12 Aug 2011 at 11:46

.NET Compact Framework

Are there plans to support the .NET Compact Framework?

Original issue reported on code.google.com by [email protected] on 13 Jul 2009 at 12:38

protogen --proto_path=<path> cannot have a space in <path>

What steps will reproduce the problem?
1. put a .proto file somewhere in a path with a space in it
2. attempt to run protogen using the absolute path for the .proto file and 
--proto_path= parameter
3. this doesn't work, and neither does quoting the --proto_path parameter 
(example: protogen "--proto_path=c:\foo bar\test.proto" "C:\foo bar\test.proto"

What is the expected output? What do you see instead?
I would expect to be able to quote the entire parameter as in 
"--proto_path=c:\foo bar\" and have it generate .cs files, but it fails with an 
error.

What version of the product are you using? On what operating system?
2.3.0.277, Windows XP

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 4 Oct 2011 at 4:52

NAnt Build Fails

What steps will reproduce the problem?
1. Run "nant clean build test dist"

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

The build fails with "Failed to start MSBuild." Running nant with -debug
shows that "MSBuild can only read solution files between version 7.0 and
9.0, inclusive." But ProtocolBuffers.sln appears to be a VC10 file.

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

Latest from subversion.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 14 Mar 2010 at 2:16

About protobuf-csharp-port specific option extensions

from wiki i know i can use option extensions with protbuf-csharp-port:
.proto file
message Msg {
   required string name = 1 [(google.protobuf.csharp_field_options).msg_type = 11];
   required string pswd = 2;
}
but can i use it like in c++:
.proto file
message Msg {
      option (msg_type) = 11;
      required string name = 1;
      required string pswd = 2;
}
how can i do that

Original issue reported on code.google.com by [email protected] on 20 Jul 2011 at 3:02

Inconsistent handling of nulls

I am playing around with the C# protobuf implementation and I might have 
run into a problem.

When calling the RpcCallback with a null IMessage, the c# protobuf impl 
crashes in the AbstractBuilder with a null reference exception.

The funny thing is that when I run with a Java client, the java protobuf 
impl does not crash with a NullException. I attached a pic in the end 
pointing to the exception.

Looking at the 2 implementations, there a small difference on how the Java 
and C# protobuf were implemented:

JAVA

  public static <Type extends Message>

  RpcCallback<Message> generalizeCallback(
      final RpcCallback<Type> originalCallback,
      final Class<Type> originalClass,
      final Type defaultInstance) {
    return new RpcCallback<Message>() {
      public void run(Message parameter) {
        Type typedParameter;
        try {
        //This does not throw an exception if called with null Message.
        // So we don't fall into the catch stmt, avoiding the Null 
Exception at MergeFrom
          typedParameter = originalClass.cast(parameter);
        } catch (ClassCastException e) {
          typedParameter = copyAsType(defaultInstance, parameter);
        }
        originalCallback.run(typedParameter);
      }
    };
  }

C#
public static Action<IMessage> GeneralizeCallback<TMessage, TBuilder>
    (Action<TMessage> action, TMessage defaultInstance)
    where TMessage : class, IMessage<TMessage, TBuilder>
    where TBuilder : IBuilder<TMessage, TBuilder> {
   return message => {
      //This is null. So we fall into the if stmt, causing a Null Exception 
at MergeFrom
      TMessage castMessage = message as TMessage; 
      if (castMessage == null) { 
          castMessage = 
defaultInstance.CreateBuilderForType().MergeFrom(message).Build();
      }
      action(castMessage);
   };
}

Is there a way the cast done in the C# implementation could be done
differently such that both implementations would be consistent?

Original issue reported on code.google.com by jonathan.skeet on 12 Mar 2009 at 7:30

Message classes generated have a public default constructor

What is the problem?

  All messages generated do not define a constructor and therefor have a default public constructor.  

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

  Messages should be obtained from a Builder class or the DefaultInstance static property.

Original issue reported on code.google.com by [email protected] on 23 Sep 2011 at 4:23

Support for decorating classes [Serializable]

As of Java 2.4.0:
  * Generated messages now implement Serializable.

Original issue reported on code.google.com by [email protected] on 19 Aug 2011 at 3:41

LITE framework edition of Google.ProtocolBuffers.Serialization

Need to add a copy of the existing project  
Google.ProtocolBuffers.Serialization that builds against the LITE assembly and 
outputs: Google.ProtocolBuffersLite.Serialization

Original issue reported on code.google.com by [email protected] on 1 Oct 2011 at 3:25

default value for enumerate fields must be filled out

What steps will reproduce the problem?
1. proto file with a enum and a message with a field of that enum type
2.do not set a default value for the enum type field
3.C# generated code compilation fails

What is the expected output? What do you see instead?
Was expecting for the generator to just leave the variable un-initialized

What version of the product are you using? On what operating system?
0.9.1 on Windows 2008 R2

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 1 Apr 2011 at 11:06

Decorate fields with [deprecated=true] as [System.Obsolete]

As of Java 2.4.0
  * Fields with [deprecated=true] will be marked with @Deprecated in Java.

Original issue reported on code.google.com by [email protected] on 19 Aug 2011 at 3:44

Add a JSON transcoding of protocol buffer messages

When used in public APIs, fact that TextFormat is the only available debugging 
representation in this library can unintentionally create an attractive 
nuisance.  The following message demonstrates the issue:
http://groups.google.com/group/transit-developers/msg/04b596e4ec2817d5

Having a readily-accessible JSON transcoding in the library would reduce the 
likelihood of users coming to depend on parsing the TextFormat representation.

Original issue reported on code.google.com by [email protected] on 26 Aug 2011 at 1:19

Disable CLSCompliant warnings

Classes generated by protogen feature the CLSCompliant attribute, however in an 
assembly that is not marked as CLSCompliant this will generate warning CS3021 
('<class>' does not need a CLSCompliant attribute because the assembly does not 
have a CLSCompliant attribute).

My suggestion would be to add 3021 to the pragma warning disable list. I can't 
think of any reason anyone would actually be interested in this warning.

Original issue reported on code.google.com by [email protected] on 27 Feb 2012 at 9:01

Circular message dependencies result in null defaults for DefaultInstance

This issue was brought to light by the new reusable builders (issue-22) usage 
of DefaultInstance.  The following proto and test demonstrate the issue...

Proto:

    message MyMessageAReferenceB {
      required MyMessageBReferenceA value = 1;
    }

    message MyMessageBReferenceA {
      required MyMessageAReferenceB value = 1;
    }

Test: 

    MyMessageAReferenceB ab = MyMessageAReferenceB.DefaultInstance;
    Assert.IsNotNull(ab);
    Assert.IsNotNull(ab.Value);
    MyMessageBReferenceA ba = MyMessageBReferenceA.DefaultInstance;
    Assert.IsNotNull(ba);
    Assert.IsNotNull(ba.Value);  < EXCEPTION: ba.Value == null

Original issue reported on code.google.com by [email protected] on 23 Sep 2011 at 2:30

Question: is protobuf-csharp-port compatible with lastest protobuf-2.2.0?

Thanks Jon.

Original issue reported on code.google.com by [email protected] on 13 Nov 2009 at 8:35

Add support for Portable Libraries


This would help when sharing code between a client (e.g. Silverlight, Metro) 
and a server (common protobuf definitions and code based on them).

It is feasible with a few changes when starting from the Silverlight projects. 
I have done it myself, but I am not sure if it is all OK as I don't understand 
the code well enough to evaluate the impact of the changes.

Original issue reported on code.google.com by [email protected] on 2 Jul 2012 at 1:11

About 15 records limit.

What steps will reproduce the problem?
1. When the proto file is complex like:
message A{
  message B{
   ...
  }
  message C{
   ...
  }
  required B myB=1;
  repeated C myC=15;
}
2.
3.

What is the expected output? What do you see instead?
  This protocol is designed for Internet usage. We want that server and client using this proto file can connect to eache other correctly.The Server side using C++ of ProtoBuf; The Client side use this protobuf-csharp-port to generate source code.

   As pointed, when C part of message A has been responsed a 14 items response to the client, all things can parsed correctly; But when the server had a response more then(or equal to) 15 items of C part, It will report error information on client:
"""""
     Unhandled Exception: Google.ProtocolBuffers.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero).
  at Google.ProtocolBuffers.CodedInputStream.ReadTag () [0x00000] in <filename unknown>:0 
  at LX_RESP_ENVELOPE+Types+LX_RESP+Builder.MergeFrom (Google.ProtocolBuffers.CodedInputStream input, Google.ProtocolBuffers.ExtensionRegistry extensionRegistry) [0x00000] in <filename unknown>:0 
  at Google.ProtocolBuffers.AbstractBuilder`2[TMessage,TBuilder].WeakMergeFrom (Google.ProtocolBuffers.CodedInputStream input, Google.ProtocolBuffers.ExtensionRegistry registry) [0x00000] in <filename unknown>:0 
  at Google.ProtocolBuffers.CodedInputStream.ReadMessage (IBuilder builder, Google.ProtocolBuffers.ExtensionRegistry extensionRegistry) [0x00000] in <filename unknown>:0 
  at LX_RESP_ENVELOPE+Builder.MergeFrom (Google.ProtocolBuffers.CodedInputStream input, Google.ProtocolBuffers.ExtensionRegistry extensionRegistry) [0x00000] in <filename unknown>:0 
  at LX_RESP_ENVELOPE+Builder.MergeFrom (Google.ProtocolBuffers.CodedInputStream input) [0x00000] in <filename unknown>:0 
  at Google.ProtocolBuffers.AbstractBuilder`2[TMessage,TBuilder].MergeFrom (System.Byte[] data) [0x00000] in <filename unknown>:0 
  at LX_RESP_ENVELOPE.ParseFrom (System.Byte[] data) [0x00000] in <filename unknown>:0 
"""""
   where LX_RESP_ENVELOPE is like the "message A" mentioned above.


What version of the product are you using? On what operating system?
We are using the protobuf-csharp-port V0.9.1; On Linux operation, Mono based.


Please provide any additional information below.
for the server response information ,the protbuf-csharp-prot can only process 
14 repeated sub messages; we had proved that all bytes send from server had 
been received by the client using protobuf-csharp-port.

Original issue reported on code.google.com by [email protected] on 25 Apr 2011 at 11:52

Writing a message with a packed sequence without finding the serialized size first fails to encode the right length

If you have a message with a packed repeated field, and serialize it straight 
to a System.IO.Stream, we don't check the serialized size - so we never work 
out the serialized size of the packed field, leading to problems when 
parsing.

Original issue reported on code.google.com by jonathan.skeet on 19 May 2010 at 7:09

Generated nested static Types class should be partial

The generated protobuf code looks a lot like:
public static partial class Umbrella {
    public sealed partial class Outer {
        public static class Types {
            public sealed partial class Inner {

It is not possible to extend the Inner partial class as the Types class is not 
marked as partial.

I believe line 245 of ProtoGen/MessageGenerator.cs needs changing.

What steps will reproduce the problem?
1. Run ProtoGen on a .proto file (with nested messages)
2. Look at the generated

What version of the product are you using? On what operating system?
2.4.1.473 on Windows 7-64bit

Original issue reported on code.google.com by [email protected] on 4 Sep 2012 at 7:59

The XML serializer will fail to deserialize a message with empty child message

What steps will reproduce the problem?
1.  Create a proto with a child message
2.  Serialize the message to XML with the child message set to DefaultInstance
3.  Read the message, all fields after the empty <child/> will be lost

Json/Binary function as expected.

Original issue reported on code.google.com by [email protected] on 10 Oct 2012 at 8:17

Add support for NuGet packages

1. Add support for publishing NuGet packages
2. Publish the existing 2.3.277 release package

Original issue reported on code.google.com by [email protected] on 10 Sep 2011 at 3:36

Undefined classes under .NET CF

I try to build test project for .NET CF 3.5 with WM 5.0 SDK. I've build the 
Lite library for .NET CF by defining COMPACT_FRAMEWORK_35 and(!) SILVERLIGHT 
because some code that files to compile (for example CustomSerialization.cs) is 
inside SILVERLIGHT condition only.

After compiling library I write simple .proto file and try to compile test 
project (I've added library to dependencies). But compilation failes because:
* Namespace system does not contain CodeDom.
* Classes pbd::MessageDescriptor, pb::FieldAccess, pbd::FileDescriptor are not 
defined.

Original issue reported on code.google.com by bvgulay on 6 Feb 2012 at 1:53

AddRange in GeneratedBuilder iterates twice.

When adding a IEnumerable of built items, where the built item is being pulled 
through a pipeline that calls Build on it [.Select(i => i.Build())], Build will 
throw an exception the second time because GeneratedBuilder<>.AddRange iterates 
on the IEnumerable twice:

        protected void AddRange<T>(IEnumerable<T> source, IList<T> destination)
        {
            ThrowHelper.ThrowIfNull(source);
            // We only need to check this for nullable types.
            if (default(T) == null)
            {
                ThrowHelper.ThrowIfAnyNull(source);
            }
            List<T> list = destination as List<T>;
            if (list != null)
            {
                list.AddRange(source);
            }
            else
            {
                foreach (T element in source)
                {
                    destination.Add(element);
                }
            }
        }


I would expect a passed in IEnumerable only to be iterated on once, so that 
means the null check will have to be dropped, or the List<>.AddRange will have 
to be dropped.  Like so:

        protected void AddRange<T>(IEnumerable<T> source, IList<T> destination)
        {
            ThrowHelper.ThrowIfNull(source);
            foreach (T element in source)
            {
                ThrowHelper.ThrowIfNull(element);
                destination.Add(element);
            }
         }


There may be other places that the IEnumerable is iterated through more than 
once.  These should be fixed as well.

Original issue reported on code.google.com by [email protected] on 12 Sep 2011 at 4:07

Remove XML documentation output from test projects to clear warnings/errors.

In the Google.ProtocolBuffers.Test project, the XML documentation is turned on, 
and all warnings are errors.  While the specific code (1591) for XML 
documentation is disabled, it still shows up as an error in ReSharper.

I propose removing the output in the test projects.

Original issue reported on code.google.com by [email protected] on 16 Sep 2011 at 3:35

How to get the type of packet received?

How to get the type of packet received?

Original issue reported on code.google.com by [email protected] on 7 Mar 2012 at 8:00

Class cannot be static and sealed error

The generated class for the attached .proto file has errors when compiling
the project:

"Eine Klasse kann nicht gleichzeitig statisch und versiegelt sein."
which means: A class cannot be static and sealed at the same time.

When I fix this there are more errors.

Original issue reported on code.google.com by [email protected] on 9 May 2010 at 12:34

Attachments:

ServerMessage.proto

SetOrClearFoo to handle null when setting values

There's some discussion about handling of null values when setting a property 
and not throwing exception:
http://code.google.com/p/protobuf/issues/detail?id=57

It will be good of protobuf-csharp-port generates this SetOrClearFoo accessor 
by default for all properties. :)

Original issue reported on code.google.com by [email protected] on 23 Aug 2012 at 4:25

Silverlight Unit Testing

If we are to continue support of Silverlight we really need to get a minimal 
set of unit tests running.  From a brief glance online, this is available in 
the Silverlight Toolkit.

Original issue reported on code.google.com by [email protected] on 1 Oct 2011 at 3:33

Descriptor namespace missing in generated code when handling import


When using the default namespace derived from the package the namespace is 
missing from the descriptor in the generated code. 

Repro steps:

Compile foo.proto with protogen.exe:
protogen.exe -output_directory=out\ -umbrella_classname=extensions 
-cls_compliance=false --error_format=msvs 
--proto_path=..\protobuf\protobuf-2.4.1\src --proto_path=. foo.proto 
--include_imports

Generates the following:

45      pbd::FileDescriptor.InternalBuildGeneratedFileFrom(descriptorData,
46          new pbd::FileDescriptor[] {
47          global::foo.Descriptor,
48          }, assigner);

At line 47 it refers to global::foo.Descriptor where it should refer to 
global::bar.foo.Descriptor.

Workaround: Adding -namespace=bar on the command line generates the correct 
code in foo.cs

Original issue reported on code.google.com by [email protected] on 26 Apr 2012 at 7:21

Attachments:

Add option to mark generated code with attribute

Thanks for this really nice port of PBs to C#.

I'd like to exclude the generated code from code coverage analysis, for 
which I have the standard attribute CoverageExclude.

I'd love an option like this:

option (google.protobuf.csharp_file_options).class_attribute = 
"(namespace).CoverageExclude";

Until then I'm just running a find and replace for "public sealed partial 
class". :)

Cheers.
Ben

Original issue reported on code.google.com by [email protected] on 16 Jul 2009 at 3:59

ProtoTest proposal

Hello,

I have read about the ProtoBench script benchmark upcoming feature.
I thought it would be a great thing, if we could write scripts for unit testing 
of components that use ProtoBufs to communicate.

For example something like this:

test ThatCoffeeMachineResponds
{
      message MakeCoffee mc;
      mc.Type = "Espresso";
      mc.Sugar = 0;
      serialize mc;
      // ...
}

There is a need to elaborate on how to plug in a transport service for the 
messages.

Original issue reported on code.google.com by [email protected] on 26 Jan 2012 at 12:13

Does not integrate well with other tooling

The code generated by protogen does not in any way demarcate code as generated. 
Thus, it does not integrate well with tooling such as Code Analysis and Style 
Analysis. This is important if code generated by protogen is included in the 
same project as non-generated code.

I suggest the following changes:

1. Wrap all generated files in:

#pragma warning disable
// code here
#pragma warning restore

This ensures any warnings in the generated code are suppressed. This is 
important to avoid noise in warning lists, and also for those of us who have 
warnings as errors enabled.

2. Place a [CompilerGenerated] attribute on all types. This allows Code 
Analysis and other binary-based tools to safely ignore the type.

3. Place the following at the top of each generated file:

// <auto-generated />

This allows Style Analysis and other source-based tools to safely ignore the 
file.

Original issue reported on code.google.com by [email protected] on 1 Aug 2011 at 9:52

Support for negative enum values

What steps will reproduce the problem?

looking at these changes in java 2.4.1:
http://code.google.com/p/protobuf/source/detail?r=381

It appears we have the same issue, writing a raw32variant.  In fact this should 
use the zig-zag variant form.  i.e. computeInt32SizeNoTag, WriteInt32

This should be addressed in both CodedOutput.WriteEnum, and ComputeEnumSizeNoTag

Original issue reported on code.google.com by [email protected] on 19 Aug 2011 at 3:34

Use of 'item' as a field name in a message causes AmbiguousMatchException

What steps will reproduce the problem?
1. Define a message:
  message Foo {
    optional int32 item = 1;
  }

2. Compile it using:
  ProtoGen.exe -ignore_google_protobuf=true foo.proto google/protobuf/csharp_options.proto --proto_path="./" -output_directory="generated/csharp/"

3. Call the constructor on this or any other Builder defined, you get the same 
exception.

Test method ing.Tests.Foo.Test threw exception: 
System.TypeInitializationException: The type initializer for 'Foo' threw an 
exception. ---> System.TypeInitializationException: The type initializer for 
'Protos' threw an exception. ---> System.Reflection.AmbiguousMatchException: 
Ambiguous match found.

System.RuntimeType.GetPropertyImpl(String name, BindingFlags bindingAttr, 
Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)
System.Type.GetProperty(String name)
Google.ProtocolBuffers.FieldAccess.SinglePrimitiveAccessor`2..ctor(String name)
Google.ProtocolBuffers.FieldAccess.FieldAccessorTable`2.CreateAccessor(FieldDesc
riptor field, String name)
Google.ProtocolBuffers.FieldAccess.FieldAccessorTable`2..ctor(MessageDescriptor 
descriptor, String[] propertyNames)
Protos.<.cctor>b__0(FileDescriptor root) in C:\local 
source\Test\generated\csharp\Protos.cs: line 127
Google.ProtocolBuffers.Descriptors.FileDescriptor.InternalBuildGeneratedFileFrom
(Byte[] descriptorData, FileDescriptor[] dependencies, 
InternalDescriptorAssigner descriptorAssigner)
Protos..cctor() in C:\local source\Test\generated\csharp\Protos.cs: line 144
Protos.get_Descriptor()
Protos.Foo..cctor() in C:\local source\Test\generated\csharp\Protos.cs: line 
1787
Protos.Foo.get_DefaultInstance()
Protos.Foo.Builder..ctor() in C:\local source\Test\generated\csharp\Protos.cs: 
line 1124

What version of the product are you using? On what operating system?
ProtoGen 2.4.1.473
Windows Server 2008 R2 x64 (tried Windows 7 x64 as well)
Visual Studio 2010 Professional
.Net Framework 4.0 Class Library project

Please provide any additional information below.

Changing the field name from "item" to "bar" causes the issue to go away.  The 
type of the field does not matter, nor does it's optional-ness.

Note that this issue causes all messages defined within the umbrella class to 
break in the same way.  It does not show up at compile time, only when the 
constructor is actually called.

Original issue reported on code.google.com by [email protected] on 31 May 2012 at 6:14

CLSCompliantAttribute even if not needed

What steps will reproduce the problem?
Run protogen.exe myproto.proto

When compiling you might get warning
'A' does not need a CLSCompliant attribute because the assembly does not have a 
CLSCompliant attribute.

The problem is that ProtoGen puts CLSCompliantAttribute even if it is not 
needed.

Two solutions are possible:
1. Add option to not put CLSCompliantAttribute.
2. Add option to ignore warnings.

Original issue reported on code.google.com by [email protected] on 18 Apr 2012 at 2:58

Upgrade protoc.exe to 2.4.1

Need to update the protoc compiler.

Once updated, will need to verify LITE framework services which can now be 
generated.

Original issue reported on code.google.com by [email protected] on 30 Sep 2011 at 2:37

ebceu4 / protobuf-csharp-port Goto Github PK

protobuf-csharp-port's People

Watchers

protobuf-csharp-port's Issues

Recommend Projects

Recommend Topics

Recommend Org