Open GoogleCodeExporter opened 8 years ago
That is very odd - I'll have to try and repro, as this is very bizarre. Do you
perhaps have an existing complete demo Project for this ?
Original comment by marc.gravell
on 9 Jan 2011 at 11:48
Any update on this? This is holding us from migrating to protobuf-net as we
always set maxItemsInObjectGraph="2147483647". Is there an attribute like that
in protobuf-net?
Many thanks in advance
Original comment by mike...@gmail.com
on 10 Feb 2011 at 10:28
That error is coming from WCF, not protobuf-net ; I do not have a repro - if
there is anything you can show to help me repro, that would help...
Original comment by marc.gravell
on 10 Feb 2011 at 11:15
I have the same problem. We want to use protobuf along with
DataContractSerializer. As far as I can see the problem is that
ProtoEndpointBehavior replaces the DataContractSerializerOperationBehavior by
ProtoOperationBehavior within ApplyDispatchBehavior which is invoked during
host.Open(). In our case we set the MaxItemsInObjectGraph property of any
DataContractSerializerOperationBehavior to a higher value. This is done before
host.Open() gets invoked, of course. So we end up changing all opBehaviors
before starting and on startup all those behaviors get replaced by your
ProtoEndpointBehavior. Too bad ProtoOperationBehavior is internal :(
Not sure if this matters but we don't use configuration files. All wcf settings
are done within code.
Original comment by roberto....@qoniac.com
on 11 Feb 2011 at 3:44
I have temporary fixed this problem with a copy of ProtoOperationBehavior and
XmlProtoSerializer<T> in my project. I repaced the
DataContractSerializerOperationBehaviors on my own (and changed MaxItems... on
the new behaviors) and removed the ProtoEndpointBehavior. This basically solved
the issue.
Original comment by roberto....@qoniac.com
on 11 Feb 2011 at 4:02
I am having the exact same issue. I am also doing the same thing roberto was
doing (config wcf client in code and changing each opbehaviors to apply a
larger MaxItemsInObjectGraph). That value is lost after using
ProtoEndpoingBehavior.
Original comment by dep...@gmail.com
on 16 Apr 2011 at 3:01
[deleted comment]
[deleted comment]
I too am experiencing the same issue.
In the meantime, I've been using this workaround which will hopefully help
someone else. Basically, I just made a wrapper that has as properties the
arrays that I am trying to serve:
[ProtoContract]
public class MyClass
{
[ProtoMember(1)]
public MyObject[] MyObjects { get; set; }
}
That seemed to allow me to bypass the MaxItemsInObjectGraph limitation. Hope
it helps someone.
Original comment by dlee33...@gmail.com
on 31 Jan 2012 at 8:39
@dlee33777 - can I clarify; what was in the *original* contract? was it a
`MyObject[]` directly?
Original comment by marc.gravell
on 31 Jan 2012 at 8:52
@marc.gravell
Yes, I was trying to pass MyObject[].
Actually, I was passing int[] and MyObject[]. I just included 1 of the arrays
in my example for simplicity.
Original comment by dlee33...@gmail.com
on 31 Jan 2012 at 8:57
Any updates regarding this... it still seems to be an issue in r580.
Original comment by jeff.a.z...@gmail.com
on 6 Sep 2012 at 6:03
Here is a patch that works for me.
@marc.gravell, would you consider integrating it ?
Thanks,
Original comment by michel.r...@gmail.com
on 23 Oct 2012 at 3:01
Attachments:
Sure - patch gratefully received.
Original comment by marc.gravell
on 23 Oct 2012 at 3:04
Original issue reported on code.google.com by
int...@gmail.com
on 9 Jan 2011 at 11:27