The basics

 XSD vs Dingo
 Class Diagram
 NUnit Tests
 Java code

 Custom Builders




This is intended to be a quick step-by-step instruction for using Dingo. If you haven't downloaded the latest distribution of Dingo, go to and click the download link. If you're not familiar with how sourceforge works, it is pretty straight forward.

  1. click on the newest release
  2. select the mirror site to download from
  3. a download dialog window will pop up
  4. select the place where you want to save the file
  5. click ok
After the file has completed the download, extract the file using Winzip or some other zip utility. Once the files are extracted, they're organized in five directories


  • bin - contains the executable and dll
  • core - the main Dingo VS.NET project
  • ndocs - API docs generated using NDoc
  • samples - sample included with Dingo
    • contact - contact example from JWSDP
    • foobar - foobar example from JWSDP
    • geneology - example of a recursive object structure
    • interfaceSample - example of how to write a plugin
    • order - simple order
    • po - po example from JWSDP
    • schemas - some sample schemas
  • site - the files for Dingo website. I will probably rename this in the future to docs
  • unitTest - directory for unit tests. I haven't written any unit tests yet.
Dingo uses VS.NET configuration files. In the "Dingo/bin/" directory is "Dingo.exe.config". The basic properties of Dingo is explained below.

<?xml version="1.0" encoding="utf-8" ?>
		<add key="autoLoad" value="false"/>
		<add key="elementExtendBaseType" value="true"/>
		<add key="licenseFile" value=""/>
		<add key="nameSpace" value="test"/>
		<add key="useInterfaces" value="false"/>
		<add key="useAbstractClass" value="false"/>
		<add key="useJXBExtend" value="false"/>
		<add key="outputPath" value="/test"/>
		<add key="assembly" value=""/>
		<!-- add key="assembly" value="./interfaceSample.dll"/ -->
		<add key="defaultBuilder" value="woolfel.schema.builder.TypeBuilder"/>
		<add key="supportXmlSerializer" value="true"/>
		<add key="systemType" value=""/>
		<!-- add key="systemType" value="woolfel.dingo.example.PropertyChange"/ -->
		<add key="woolfel.dingo.example.PropertyChange" 
		<add key="delegateFields" value="false"/>
		<add key="delegateMethods" value="true"/>
		<add key="delegateProps" value="false"/>

autoLoad - I've decided to delay this until the next release. The idea of autoload is Dingo will load the assemblies and scan for any classes that implement DelegateBuilder interface.
elementExtendBaseType - The default is set to true. In this mode, an element that uses a defined complexType or simpleType will simply extend the type. When set to false, the fields will be copied to the element and it will not extend the base type.
licenseFile - If you want the generated code to use a specific license, simply edit the value to use the full path of your license file in text format.
nameSapce - if the schema does not have a namespace declaration, it will use the namespace provided in the config. If a namespace is provided in the schema, it will be used instead.
userInterface - Dingo will generate interfacs and concrete classes
useAbstract - I've decided to delay this for the next release. I am still deciding the best way to implement support for using abstract classes with interfaces and concrete classes.
useJBXExtend - Dingo will read jxbextend properties in the schema.
outputPath - Dingo will save the generated source to the given directory.
assembly - Comma separated list of assemblies to load.
defaultBuilder - If you wish to use a different builder, change the value.
systemType - Comma separated list of interfaces or base classes. Each value is then used to load the name of the delegating builder.
delegateFields - When it is set to true, Dingo will look for a registered builder and use it to generate the source for fields.
delegateMethods - When it is set to true, Dingo will look for a registered builder and use it to generate the source for methods.
delegateProps - When it is set to true, Dingo will look for a registered builder and use it to generate properties.

Dingo is unlike Microsoft and Mono XSD in this area. Rather than use command options, I've decided to use the configuration file. Since the settings are more complex than a simple "/c", I figured it would be better to use the config file. Later on, I hope to write a GUI tool for Dingo, but that is scheduled for the second release.


To run Dingo, all you need is the standard .NET 1.1 release, or the latest Mono release.

Updated 9-10-2004 Peter Logo
Copyright 2004 Peter Lin