Why does WCF sometimes add "Field" to end of generated proxy types?

Question

Basically, I have a server-side type "Foo" with members X and Y. Whenever I use Visual Studio's "Add Server Reference" then I see the WSDL and the generated proxy both append the word "Field" to all the members and change the casing of the first letter. IE, "X" and "Y" are renamed "xField" and "yField". Any idea why this is happening? I can't figure out the pattern.

Details -- I have a legacy ASMX web service which exposes a "Foo" type. I created a new WCF service that's a wrapper around that old web service -- the new service just wraps those methods and maybe updates the values of a few fields, but it exposes the exact same methods and returns the exact same types. I've tried re-creating the referenes several times, and every time, it always renames my fields: the varible "STUFF" is exposed in the wsdl and proxy as "sTUFFField". Variable "X" is exposed as "xField", etc.

Funny thing is I can't figure out the pattern -- I tried creating a new ASMX web service as a test and wrapping that -- variables are not renamed then. So I can't figure out the pattern of why/when WCF renames variables.

Anybody know?

It does matter. I have two use cases (for internal vs external users). The internal users can bypass my wrapper service and go directly to the underlying legacy service (thereby bypassing the need to login). The external users have to go through the wrapper service and give it a password, etc. But since the internal and external services now give different names to the fields, I can't share the same code to talk to both services. I need to write different versions of the code for each service. — tavistmorph, Jul 22 '09 at 14:07

score 25 · Answer 1 · edited Dec 12 '14 at 09:42

25

I had the same issue, and sergiosp's answer got me headed in the right direction. Just adding some additional info to hopefully help someone else.

Adding [System.ServiceModel.XmlSerializerFormatAttribute()] to the interface, and re-generating the client code resolved the problem for me.

public interface IMyService
{
    [System.ServiceModel.XmlSerializerFormatAttribute()]
    [System.ServiceModel.OperationContract]
    recordResponse GetRecord(recordRequest request);

}

edited Dec 12 '14 at 09:42

user247702

23,641
15
110
157

answered Sep 20 '11 at 22:41

tgriffin

483
1
5
13

thanks for the help. It solved for me as well but do you have any idea what is that code doing and how is it solving the problem? – Emil Nov 15 '13 at 14:20
1

@batmaci When you "Add Service Reference" in Visual Studio, WCF is generating client code to call the service. It will use the DataContractSerializer by default. Adding the XmlSerializerFormatAttribute causes WCF to generate the code using the XmlSerializer. Try adding a service reference once with the XmlSerializerFormatAttribute and once without, and compare the differences in the generated code file (Reference.cs). – tgriffin Dec 13 '13 at 06:33
I can't believe this answer has been sitting here for 2 years. I have been searching madly through SO and the web for this answer. This is literally an answer to my prayer. In case it is of any use to you people of the future who encounter this same problem, [here](http://stackoverflow.com/a/20713299/2453110) is the link to my similar question about building a DocuSign event listener for their Connect notification service. – Mark Bailey Dec 20 '13 at 23:10
1

common people if you had ReSharper installed you'd realize you have a log of clutter. It's unnecessarily to put the () in attributes, clean code, common..all this clutter makes stuff...well clutter – PositiveGuy Dec 02 '14 at 04:34
1

I had this issue with classes generated from XSDs, with XML serialization attributes. I don't know if that is what causes the issue, but I guess it makes sense to use `[XmlSerializerFormat]` when the classes use XML serialization. – user247702 Dec 12 '14 at 09:42
Thank you! I was trying to use DataContract Surrogates and it wasn't working, this did the trick! – Norman H Nov 09 '15 at 16:29

score 4 · Answer 2 · answered Sep 02 '10 at 13:56

I had the same problem but i was able to find solution.

In the interface if you add [DataContractFormat] tag you will end up with "XFieldField" case. But if you replace it with [XmlSerializerFormat] in the interface it will not change the names in the proxy generated.

marc_s · Answer 3 · 2009-07-22T13:11:03.510

3

Typically, the generated proxy will have "XField" and "YField" as internal/protected/private fields, and expose the values through properties called "X" and "Y". There are options you can set when creating the proxy client to tweak that to your liking, I think.

UPDATE: I don't seem to find any switches or options to control this behavior. It might depend on which serializer (DataContractSerializer vs. XmlSerializer) WCF uses for creating the client proxy.

In the end, it's really more or less just an issue of coding style - functionally, it shouldn't make a difference.

Marc

edited Jul 22 '09 at 13:11

answered Jul 22 '09 at 12:35

marc_s

732,580
175
1,330
1,459

Right, that's how it NORMALY works, but I'm seeing the public fields are renamed to. So the internal fields are called "XFieldField" and the public accessor is called "XField". Not what I want, and it means the interface to the wrapper service becomes different than the interface to the actual service. So I can no longer treat the two services interchangably. – tavistmorph Jul 22 '09 at 16:05
THat's odd and unexpected - how do you create your client proxy? In Visual Studio or using svcutil.exe ?? – marc_s Jul 22 '09 at 16:59
Exactly -- odd and unexpected. It's only happening on this one project, so I can't figure out the pattern. But I created the client proxy with Visual Studio, just by clicking "Add service reference". – tavistmorph Jul 23 '09 at 13:22

score 0 · Answer 4 · edited May 15 '13 at 11:47

I had this problem too, but from the client I was still getting Field at the end of the class members even after making the mentioned change at the interface.

The problem was, I was using a DataContractSerializer to work with disk file serialized requests (during the test of our service, we were getting serialized requests from the provider, to be able to debug before going live).

After changing the DataContractSerializer to a XmlSerializer, specifying on its constructor the root element (by a typeof() call) and the rootnamespace (because by default, XmlSerializers write the standard namespace), I could deserialize the requests and work perfectly with the WCF Service.

Hope this helps somebody. I lost soooo many time with this "issue".

score 0 · Answer 5 · edited May 23 '16 at 11:39

0

Adding XmlSerializerFormat worked for me. Got solution from http://geekswithblogs.net/mipsen/archive/2010/02/06/field-postfix-in-wcf-reference.aspx

[ServiceContract(Namespace="http://somenamespace.com/contracts")]    
public interface ISchemaService
{
    [OperationContract]
    [XmlSerializerFormat]
    void DoSomething(GeneratedType data);
}

edited May 23 '16 at 11:39

CodeCaster

147,647
23
218
272

answered May 23 '16 at 11:26

NoloMokgosi

1,678
16
10

Why does WCF sometimes add "Field" to end of generated proxy types?

5 Answers5

Linked