Błąd deserializacji zewnętrznego XML po stronie konsumenta WebSerwisu (VS2010)

0

Witam wszystkich! Problem dotyczy jak sądzę rzeczy podstawowych, ale te często bywają najtrudniejsze. Słowem wstępu - w VS(Visual Studio 2010) są utworzone dwa projekty: WebSerwis (WebSite .net4) oraz lokalna aplikacja testowa go konsumująca (Add WebReference->wskazujemy WSDL).

Kluczową rzeczą jest tutaj schemat XSD, gdzie określone zostały typy danych używane do komunikacji z WebSerwisem. Na potrzeby WS została wygenerowana klasa .cs kolejno narzędziami raz xsd.exe, raz xsd2code (ustawienia domyślne). W przypadku xsd2code - próba deserializacji po stronie aplikacji Testowej (XmlSerializer.Deserialize) "gołego" XML'a (bez namespace'ów, bez prefix'ów, czyste tagi z deklaracją XML tylko) do obiektu zgodnego z typem w XSD powoduje wygenerowanie pustego obiektu (wszystkie składowe NULL'owe). W przypadku xsd.exe owa deserializacja idzie bez problemu. Deserializacja przy xsd2code działa, ale tylko wówczas, gdy w XML'u występuje albo xmlns w każdym tagu, albo w głównym + prefixy w tagach.

Na czym polega dokładnie różnica pomiędzy zastosowaniem jednego i drugiego narzędzia (xsd.exe, xsd2code) w kontekście takiego zachowania konsumenta WebSerwisu?
Jak ewentualnie zmusić Deserializer (a może się nie da) do pracy z "gołym" XML'em w przypadku uzywania narzędzia xsd2code?

Dodatkowa informacja: Po wygenerowaniu klasy narzędziem xsd2code i próbie odpalenia webserwisu (wyświetleniu WSDL'a w przeglądarce) wystąpił błąd "Niespójne sekwencjonowanie" w kontekście wygenerowanych atrybutów dot. kolejności (Order) w NIEKTÓRYCH tylko typach. Deklaracje te zostały usunięte (quick workaround) żeby WebSerwis mógł w ogóle ruszyć. Czy to mogło spowodować w/w zachowanie ? Rozumiem, że jeśli domyślnym typem są w xsd2code Listy, a nie Array'e, (z czego się wstępnie ucieszyłem) "więc coś mogło pójść nie tak"... ale tu już brakuje mi wiedzy właśnie.

0

Już sobie poradziłem... niestety bez gruntownej analizy tematu nie ma co podchodzić do implementacji. Okazuje się, że jest całe mnóstwo niuansów, które trzeba uwzględnić, od projektu XSD, poprzez wybór narzędzia do generowania klas, aż do precyzyjnego przestudiowania dokumentacji używanych klas do obsługi szeroko rozumianego XML. Nie ma prostej recepty.

Pzdr.

1 użytkowników online, w tym zalogowanych: 0, gości: 1