tags:

views:

32

answers:

2

I am using protobuf-net on the project I am working on for the data contracts, creating the .proto files by hand and having the custom tool spew forth the C# code which it is duly doing. I have also started using it for service contracts and the service interfaces are also created just fine.

For connectivity to some systems I am using WCF so I have enabled the datacontracts generator option and, although the the System.ServiceModel attributes are present, there does not appear to be any way for me to declare the specific faults the service may raise.

So my problem is basically:

  • Protocol Buffers language does not appear to have any constructs for exceptions/faults.
  • I cannot see any protobuf-net options for generating FaultContract attributes.
  • The interface generated by protobuf-net is not declared partial so I cannot augment the generated code.

Is there any way to declare service WCF operation faults in protobuf-net or is this something that I would have to wait for version 2 for?

Many thanks.

A: 

this doesnt directly answer your question but may be appropriate anyway
protobuf-net doesn't need .proto files to work, so it would be the same amount of effort to just write your C# classes and decorate them with the WCF attributes (and your FaultContract attributes) than create the proto's (manually) for the sake of generating C# classes.

wal
Thanks @wal, but I need to come at the problem from the .proto end of the stick as I need to control the layout of the messages (types) so that it is consistent with other applications in my organisation.
Paul Ruane
Paul, the only other thing I can suggest is to perhaps implement the changes yourself. I recently did this (for v1), see http://stackoverflow.com/questions/3523225/protobuf-net-and-interface-support"> which was fun, depending on your definition of fun of course. :)
wal
Well, since taking a step back, I think I'm going to have to give up on WCF faults and include error information in the response messages in order to keep the API consistent across RPC servers, as Protocol Buffers does not support the concept of exceptions/faults. Thanks for your suggestions though.
Paul Ruane
+2  A: 

I'm not sure why I don't declare that as partial interface, since that seems perfectly happy in C# 2.0; I'll get that changed when I get a second, but note that you can apply a manual change locally - simply by editing the csharp.xslt file. Now, xslt isn't everyone's cup of tea, but it should be a 1-line change (near to the word interface) - in fact, it is probably the addition of partial here:

<xsl:template match="ServiceDescriptorProto">
    <xsl:if test="($optionClientProxy or $optionDataContract)">
    [global::System.ServiceModel.ServiceContract(Name = @"<xsl:value-of select="name"/>")]</xsl:if>
    public /* HERE => */ partial /* <= HERE */ interface I<xsl:value-of select="name"/>
    {
      <xsl:apply-templates select="method"/>
    }

    <xsl:if test="$optionProtoRpc">
    public class <xsl:value-of select="name"/>Client : global::ProtoBuf.ServiceModel.RpcClient
    {
      public <xsl:value-of select="name"/>Client() : base(typeof(I<xsl:value-of select="name"/>)) { }
      <xsl:apply-templates select="method/MethodDescriptorProto" mode="protoRpc"/>
    }
    </xsl:if>
    <xsl:apply-templates select="." mode="clientProxy"/>

</xsl:template>

Since the the xslt is tweakable, you should be able to apply any other changes you require.

Marc Gravell
Ah, excellent many thanks Marc. Had no idea there were accessible templates for these. This should do the trick.
Paul Ruane