Dlaczego WCF czasami dodaje "Pole" do końca generowanych typów proxy?

Question

Zasadniczo, mam typ "Foo" po stronie serwera z członkami X i Y. Ilekroć używam "Add Server Reference" Visual Studio, wtedy widzę WSDL i wygenerowany serwer proxy oba dołączają słowo "Field" do wszystkich członków i zmienić obudowę pierwszej litery. IE, "X" i "Y" są przemianowane na "xField" i "yField". Jakiś pomysł dlaczego tak się dzieje? Nie mogę wymyślić wzoru.

Szczegóły - Mam starszą usługę sieci ASMX, która udostępnia typ "Foo". Stworzyłem nową usługę WCF, która jest opakowaniem starej usługi sieciowej - nowa usługa po prostu opakowuje te metody i może aktualizuje wartości kilku pól, ale eksponuje dokładnie te same metody i zwraca dokładnie te same typy. Próbowałem wielokrotnie odtwarzać sędziów, a za każdym razem zawsze zmieniam moje pola: zmienna "STUFF" jest widoczna w pliku wsdl i proxy jako "sTUFFField". Zmienna "X" jest widoczna jako "xField", itp.

Zabawne jest to, że nie mogę wymyślić wzoru - próbowałem stworzyć nową usługę sieciową ASMX jako test i opakowanie - zmienne nie są zmienione następnie. Tak więc nie mogę znaleźć schematu dlaczego/kiedy WCF zmienia nazwy zmiennych.

Ktoś wie?

Answer 1

Zazwyczaj generowane proxy będzie miało "XField" i "YField" jako pola wewnętrzne/chronione/prywatne i ujawni wartości poprzez właściwości o nazwach "X" i "Y". Istnieją opcje, które możesz ustawić podczas tworzenia klienta proxy, aby dostosować go do własnych potrzeb, jak sądzę.

AKTUALIZACJA: Nie widzę żadnych przełączników ani opcji kontrolujących to zachowanie. To może zależeć od tego, który serializator (DataContractSerializer vs. XmlSerializer) WCF używa do tworzenia proxy klienta.

W końcu jest to mniej więcej kwestia stylu kodowania - funkcjonalnie nie powinno to mieć znaczenia.

Marc

Answer 2

miałem ten sam problem, ale udało mi się znaleźć rozwiązanie.

W interfejsie, jeśli dodasz znacznik [DataContractFormat], otrzymasz wynik "XFieldField". Ale jeśli zastąpisz go [XmlSerializerFormat] w interfejsie, nie zmieni to nazw w generowanym proxy.

Answer 3

Miałem ten sam problem, a odpowiedź sergiosp doprowadziła mnie w dobrym kierunku. Po prostu dodam dodatkowe informacje, aby pomóc komuś innemu.

Dodanie [System.ServiceModel.XmlSerializerFormatAttribute()] do interfejsu i ponowne wygenerowanie kodu klienta rozwiązało problem dla mnie.

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

} 

Answer 4

miałem ten problem też, ale od klienta ja wciąż coraz Field na koniec członków klasy nawet po dokonaniu powyższej zmiany w interfejsie.

Problem polegał na tym, że używałem DataContractSerializer do pracy z żądaniami serializowanymi plików na dysku (podczas testu naszej usługi otrzymywaliśmy od dostawcy szeregowe żądania, aby móc debugować przed uruchomieniem).

Po zmianie DataContractSerializer do XmlSerializer, podając na jej konstruktora element główny (przez typeof() rozmowy) i rootnamespace (bo domyślnie XmlSerializers napisać standardowej przestrzeni nazw), mogę deserializowania żądań i doskonale współpracować z Usługa WCF.

Mam nadzieję, że to pomoże komuś. Straciłem tak wiele czasu z tym "problemem".

Answer 5

Dodanie XmlSerializerFormat zadziałało. Masz rozwiązanie od 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); 
}