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 thoughts on “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.

Leave a Reply to Greg Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s