blocks|key|1497760|text|通常，生成的代理将具有"XField“和"YField”作为内部/受保护/私有字段，并通过名为"X“和"Y”的属性公开这些值。我认为，在创建代理客户端时，您可以设置一些选项来根据自己的喜好进行调整。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1497761|更新:我似乎没有找到任何开关或选项来控制这种行为。这可能取决于哪个序列化程序(DataContractSerializer与XmlSerializer)用于创建客户端代理。|1497762|最后，这实际上或多或少只是一个编码风格的问题--从功能上讲，这不应该有什么不同。|1497763|Marc|1497764|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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

blocks|key|1283021|text|我也有同样的问题，但我找到了解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1283022|在界面中，如果你添加了DataContractFormat标签，你将以"XFieldField“结尾。但是，如果您在接口中将其替换为XmlSerializerFormat，则不会更改生成的代理中的名称。|1283023|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1497890|text|我也有同样的问题，sergiosp的回答让我找到了正确的方向。只是添加一些额外的信息，希望对其他人有所帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1497891|向界面添加[System.ServiceModel.XmlSerializerFormatAttribute()]并重新生成客户端代码为我解决了这个问题。|offset|length|style|CODE|1497892|public+interface+IMyService
{
++++[System.ServiceModel.XmlSerializerFormatAttribute()]
++++[System.ServiceModel.OperationContract]
++++recordResponse+GetRecord(recordRequest+request);

}|code-block|syntax|javascript|1497893|entityMap^0|0|5|1G|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

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 <code>[System.ServiceModel.XmlSerializerFormatAttribute()]</code> to the interface, and re-generating the client code resolved the problem for me.

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

}
</code></pre>

blocks|key|1497955|text|我也有这个问题，但是从客户端我仍然在类成员的末尾获得Field，即使在接口上做了上面提到的更改之后。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1497956|问题是，我使用DataContractSerializer来处理磁盘文件序列化请求(在我们的服务测试期间，我们从提供者那里得到序列化请求，以便能够在上线之前进行调试)。|1497957|将DataContractSerializer更改为XmlSerializer后，在其构造函数上指定根元素(通过typeof()调用)和根命名空间(因为在默认情况下，XmlSerializers编写标准命名空间)，我可以反序列化请求并完美地使用WCF服务。|1497958|希望这对某些人有帮助。我在这个“问题”上浪费了太多时间。|1497959|entityMap^0|Q|5|0|7|M|0|1|M|Q|D|1K|8|2B|E|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|T|8|@$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|12|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|M|$]]

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

The problem was, I was using a <code>DataContractSerializer</code> 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 <code>DataContractSerializer</code> to a <code>XmlSerializer</code>, specifying on its constructor the root element (by a <code>typeof()</code> call) and the rootnamespace (because by default, <code>XmlSerializers</code> 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".

blocks|key|1283210|text|添加XmlSerializerFormat对我来说很有效。从http://geekswithblogs.net/mipsen/archive/2010/02/06/field-postfix-in-wcf-reference.aspx获得解决方案|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1283211|[ServiceContract(Namespace="http://somenamespace.com/contracts")]++++
public+interface+ISchemaService
{
++++[OperationContract]
++++[XmlSerializerFormat]
++++void+DoSomething(GeneratedType+data);
}|code-block|syntax|javascript|1283212|entityMap|0|LINK|mutability|MUTABLE|url|http://geekswithblogs.net/mipsen/archive/2010/02/06/field-postfix-in-wcf-reference.aspx^0|U|2F|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

Adding XmlSerializerFormat worked for me. Got solution from <a href="http://geekswithblogs.net/mipsen/archive/2010/02/06/field-postfix-in-wcf-reference.aspx" rel="nofollow">http://geekswithblogs.net/mipsen/archive/2010/02/06/field-postfix-in-wcf-reference.aspx</a>

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

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?

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

Visual Studio

服务器

基本上，我有一个具有成员X和Y的服务器端类型"Foo“。每当我使用Visual Studio的"Add Server Reference”时，我看到WSDL和生成的代理都将单词"Field“附加到所有成员，并更改第一个字母的大小写。也就是说，"X“和"Y”被重新命名为"xField“和"yField”。你知道为什么会发...

问为什么WCF有时会在生成的代理类型的末尾添加"Field“？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么WCF有时会在生成的代理类型的末尾添加"Field“？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么WCF有时会在生成的代理类型的末尾添加"Field“？
EN