Unexpected behavior (with sample schema)

Dec 15, 2009 at 12:29 PM
Edited Dec 15, 2009 at 1:58 PM


Using linqtoxsd as an xsd.exe replacement can really be a treat, so thanks for the great work! I found a scenario, which doesn't seem to work correctly though.

Consider the following schema:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd"
  <xs:attributeGroup name="personattr">
    <xs:attribute name="attr1" type="xs:string"/>
    <xs:attribute name="attr2" type="xs:integer"/>

  <xs:element name="fullpersoninfo">
        <xs:extension base="personinfo">
            <xs:element name="address" type="xs:string"/>
            <xs:element name="city" type="xs:string"/>
            <xs:element name="country" type="xs:string"/>

  <xs:complexType name="personinfo">
      <xs:element name="firstname" type="xs:string"/>
      <xs:element name="lastname" type="xs:string"/>
    <xs:attributeGroup ref="personattr"/>


As you can see there is a complexType 'personinfo' referencing an attribute group and an element with enclosed complex type extending personinfo. the objectmodel created will feature a personinfo class with firstname, attr1 etc properties and a fullpersoninfo class. I would expect this class to have all the properties personinfo is having but unfortunately the referenced attributes are missing. (Code created using xsd.exe is featuring those properties).

The workaround for this scenario I found is to not use an element for fullpersoninfo but to directly declare the complexType as <xs:complexType name="fullpersoninfo">.

I Hope that helps and I also hope for a fix :)

Best regards,
Mario Topf


EDIT: I just recognized that an attribute group ref is in fact not necessary. Declaring attributes instead lead to the same behavior here.

Feb 27, 2010 at 3:42 AM

Looks like the fixed bug:


Could you check if it is still an issue?