[ProtoBehavior] is invasive

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Add the [ProtoBehavior] attribute to a WCF service method
2. Dot NOT add any protobuf-net related configuration in app.config
3. Consume the WCF service method

What is the expected output? What do you see instead?
It is expected, that protobuf-net is NOT used for 
serialization/deserialization, as long as it is not configured for the 
endpoint. It seems the [ProtoBehavior] is active even though.

What version of the product are you using? On what operating system?
.NET 4.5, protobuf-net r622

Original issue reported on code.google.com by adi.he...@gmail.com on 10 Apr 2013 at 11:35

[GoogleCodeExporter]

These are two different ways of configuring the same thing. By adding the 
attribute you *are* configuring it for the endpoint. If you want to control 
things at the config level, then: do that instead.

Is your proposal that you would only want to apply when *both* are present? 
That could probably be done, but to prevent breaks would probably need to be 
via an optional attribute property.

Original comment by marc.gravell on 10 Apr 2013 at 11:54

[GoogleCodeExporter]

They way you describe it makes perfectly sense. I didn't see the documentation 
on the class level. However it doesn't seem to work that way in very case. 

What I did:
I tryed to migrate an existing wpf based application to protobuf-net using the 
following approach:

1. Added [ProtoContract(SkipConstructor = true, UseProtoMembersOnly = false)] 
to all classes that are [DataContract]
2. Added the protobuf-net endpoint behavior to the client and the servier via 
app.config
3. Tested the communication. The service methods were properly called, but all 
members of the contract classes were null. (even though UseProtoMembersOnly was 
set to false)
4. Added the [ProtoMember(..)] attributes to all members
5. Tested again, return value of method was null
6. Added [ProtoBehavior] to all service methods
7. Tested again, now it worked

Under some circumstances, the step 6. is not required to make it work. It seems 
to depend on the hosting environment (same process/same machine..). However I 
don't know the exact pattern yet, under which circumstances the [protobehavior] 
is required or not.

On a side note: 
Your library has a huge potentional. Every application out there using shared 
contracts in WCF could highly benefit from it. However currently the 
investments to adapt protobuf-net within an existing application are high 
(Refactoring all the contracts: default-value behavior in contructors, members 
of type system.object, troubleshooting behavioral differences to 
datacontractserializer, etc). You could drastically increase your userbase by 
improving the ProtoBuf.ServiceModel.ProtoBehaviorExtension: Ideally this class 
would read the existing wcf contracts and configure the protobuf-net typemodel 
accordingly to have the same behavior as datacontractserializer. (constructor, 
handling empty/null lists, type information..) That way one could simply 
replace datacontractserializer by protobuf-net it in the app.config of client 
and server without changing a single line of code in the application. This 
would be the killer.
I imagine however, it would require a bunch of extensions to the protocol 
standards to support all the wcf features.

Best
Adrian

Original comment by adi.he...@gmail.com on 12 Apr 2013 at 10:47