XSD.exe – problem w wygenerowanych klasach przy zagnieżdżonych węzłach

W jednym z projektów spotkałem się z problemem dotyczącym wygenerowanej klasy na podstawie .xsd. Po stworzeniu kodu odpowiedzialnego za serializację i jego uruchomieniu, nagle pojawił się exception związany z wielowymiarowością tablic. W przypadku docelowej property, np. Property[][], po wygenerowaniu klasy, pojawi się w niej Property[][][].

Posłużę się prostym przykładem, żeby pokazać na czym dokładnie polegał problem.

Załóżmy, że mamy prosty plik XML o takiej strukturze:

<?xml version="1.0" encoding="UTF-8"?>
<People>
   <Person>
      <Name>Jack</Name>
      <Surname>Jakcky</Surname>
      <Salary>
         <Wages>2222</Wages>
         <Allowance>
            <Bonus>
               <ProjectBonus1>
                  <Bonus1>300</Bonus1>
                  <Bonus2>200</Bonus2>
               </ProjectBonus1>
               <ProjectBonus2>
                  <Bonus1>400</Bonus1>
                  <Bonus2>300</Bonus2>
               </ProjectBonus2>
            </Bonus>
         </Allowance>
      </Salary>
   </Person>
</People>

Następnie przy wykorzystaniu xsd.exe utworzymy plik .xsd na podstawie XML, aby tego dokonać wpisujemy w Developer Command Prompt:

xsd.exe "D:\\sample.xml" /out:"D:\\" (ścieżka do pliku XML na dysku)

Następnie generujemy klasę z pliku .xsd. W DCP wpisujemy:

xsd.exe "D:\\sample.xml" /c

Mamy teraz klasę sample.cs. Niestety, tak jak wcześniej wspomniałem, używając jej w naszej aplikacji, w momencie serializacji, VS wyrzuci nam błąd mówiący o problemach z wymiarami właściwości. Okazuje się, że rozwiązaniem jest ręczna edycja (sic!) wygenerowanej klasy, a właściwie usunięcie ostatniej [].  Oznacza to, że w przypadku properties, np. Property[][][], po zmianie będzie to wyglądało następująco: Property [][].  Drugim sposobem (zalecanym) jest edycja pliku xsd, z którego później zostanie stworzona klasa.

2 uwagi do wpisu “XSD.exe – problem w wygenerowanych klasach przy zagnieżdżonych węzłach

  1. Zdarzył mi się w pracy z generowaniem XSD taki przypadek. Doczytałem się gdzieś, że to bug w toolu do generowania pliku cs z xsd. Faktycznie – pozostało ręczna edycja klasy wygenerowanej. Mimo tego i tak wydaje mi się to szybsze i pewniejsze do serializacji, niż samemu tworzenie klasy na podstawie xml 😉

    Dołożę jeszcze dwa zdania na taki sposób:
    Niebezpiecznie jest generować xsd z pliku xml. Trzeba pamiętać, że wartości stringowe są opcjonalne i mogą nie występować z przykładowym pliku xml. Co z tym idzie xsd nie stworzy nic dla nich. A co jeśli przyjdzie plik xml posiadający te wartości? Serializacja się wysypie 🙂

    1. Zgadza się co do generowania xsd z xml, zazwyczaj tworzę xsd ręcznie. Co do bug’a, można go załatwić w jeszcze inny sposób (niedawno na to wpadliśmy). Piszesz prosty skrypt w PowerShell’u, który edytuje klasę wygenerowaną z xsd. I chyba to jest najbezpieczniejsze, jedyne o czym trzeba pamiętać to o tym, żeby po każdej zmianie w .xsd zapuścić skrypt.

Zostaw komentarz

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Connecting to %s