xsd does not contain a definition for 'Load'

Dec 1, 2009 at 9:21 PM

I have been using T4Toolbox for about a year to generate multiple files from an xml/xsd I've created.  I've been using the <#@ xsd #> directive.

Recently I upgraded to the professional version of T4 Editor so that I could use some of the modeling features to generate state machine code.  It took a bit to get this all to work.  In the processes I ended up reinstalling Visual Studio 2008 Pro and all the add-ins I could identify.

Today I went back because I needed to regenerate the code that uses the xml.  I had to change "RenderCore" to "TransformText" and add "GenerationEnvironment.ToString()" since I updated to version 9.10 of T4Toolbox for the modeling to work.  Now I keep getting this error:

Compiling transformation: 'Microsoft.VisualStudio.TextTemplating6F48679642078F0B93CDC144B39AAA10.GeneratedTextTransformation.HardwareDataType' does not contain a definition for 'Load'    c:\Projects\Visual Studio 2008\Otto\Otto\Hardware.tt

After googling I've tried the following to fix this issue:

1) Made sure I had VS 2008 Pro SP1

2) Made sure I had VS 2008 SDK 1.1

3) Upgrade to T4Toolbox 9.12

4) Reset the Microsoft VS 2008 SP1 experimental hive

5) Reset my computer - you never know

Nothing has helped.  Does anyone know of anything that changed with the xsd processor between 9.7 & 9.10?  Does anyone have any other suggestions?

I think my code is fairly straight forward:

<#@ template inherits="Microsoft.VisualStudio.TextTemplating.VSHost.ModelingTextTransformation" language="C#v3.5" hostspecific="True" debug="True" #>
<#@ output extension="txt" #>
<#@ include file="T4Toolbox.tt" #>
<#@ include file="Generators/PicGenerator.tt" #>
<#@ include file="Utilities.tt" #>
<#@ xsd processor="T4Toolbox.XsdProcessor" file="hardware.xsd" #>
<#

    string ottoPath = System.Environment.GetEnvironmentVariable("OTTO_PATH");
    if(ottoPath == null)
    {
#>
The "OTTO_PATH" environment variable is not set.
Set it by running "SetEnvironmentPath.bat" in your "Otto" project directory.
<#
    }
    else
    {
        // This is where the problem appears - Load isn't a static member of HardwareDataType anymore.
HardwareDataType hardwareData = HardwareDataType.Load(ottoPath + @"\Otto\hardware.xml"); #> Run the pic generator <# PicGenerator picGenerator = new PicGenerator(); picGenerator.HardwareData = hardwareData; picGenerator.Run(); } #>

Coordinator
Dec 2, 2009 at 7:31 AM

Nothing has changed in the XsdProcessor, as far as I know. This still works with the LINQ to SQL xsd. The Load method will be generated only if your XSD defines a root-level, non-abstract element HardwareDataType.

Dec 2, 2009 at 2:51 PM

After your comment, Oleg, I decided to go back to basics.  I tried the example that you provide in this guide: http://www.olegsych.com/2008/08/t4-xsd-directive/.  This worked.

I started looking at differences between the two xsd files.

My root element has always been:

    <!-- The HardwareData element is defined here -->
    <xs:element name="HardwareData"
                type="HardwareDataType">
    </xs:element>

This has worked without problems up until the last updates that I did.

The example xsd you give is:

  <xs:element name="TestClass" nillable="true" type="TestClass" />
  <xs:complexType name="TestClass">
    <xs:sequence>
      <xs:element name="TestProperty" type="xs:int"
                  minOccurs="1" maxOccurs="1" />
    </xs:sequence>
  </xs:complexType>

The name of the root element is the same as the type, my root element name is different than the type.

For fun I thought I'd make my name equal to the type, both equal to HardwareDataType.  I had to change the root elements of my xml, but once I did that everything worked.

I don't know what would have changed for this to make a difference, but it has.

 

Coordinator
Dec 5, 2009 at 5:55 PM

I'm glad you figured it out.

Implementation of the XSD directive in T4 Toolbox is based on the implementation of xsd.exe. If you can create a scenario that xsd.exe handles correctly but the xsd directive does not, I can look into it. Otherwise, I would like to avoid making any changes that would make the two implementations different. This is easily the most complex code in T4 toolbox.

Oleg