Scott's a very funny man and hosted a very entertaining session on code generation.  My jet lag really kicked in at the start of this session, so you might like to see Peter Provost's blog for more coverage as well as Jon Galloway:

• Jon Lam talked about the 'usability tax' from using XML. XSLT is a programming language that is hard to maintain. He prefers using PERL for writing code. XML is hard for humans to maintain.
• Scott started by talking about the CodeDOM as being 'the opposite of terse'.
• Discussion about the line between creating a generic engine versus just solving the problem with code. How do we deal with the trade-off between producing a solution to the current problem versus creating a generic non-specific approach.
• Computer languages are for people to work with, so we write in C#. It is a code generator that produces IL that produces assembly code to run. We want a higher level language to build software.
• 3 kinds of code-generation: Wizard skeleton, Compiler - template and generics, Modelling - result is not a model but an assembly
• Some discussion about whether generators were useful for producing quick and dirty one-off situations.
• Discussion about what the output of code generation should be. Is it the code files, or is it the compiled DLL?
• How do you manage changes - should you do it at compile time or run time? What about it you need to modify things after they have been generated? Should you make them plugins, use interfaces or work with the config files.
• Sometimes code-generation make it hard for others to maintain.
• Don't do the rules engine that solve the 'verbs' problem. Think about the nouns.

How Corillian do code generation:

• Scott talked about how Corillian do it. They model the nouns in a visual tool using an XML schema underneath that can be extended and allows you to create your own vocabulary. The elements on the schema come from another namespace that includes domain specific attributes.
• They then we use a free-ware tool called code-smith which lets you write code-generation syntax in an ASP.NET syntax (<% for each … %> to output the data). They use that to create the code (rather than HTML in the ASP example).
• They created an XML schema adapter that looks at an XML schema and gives you a collection of top-level types and subtypes. Then all the different places where they have domain-specific knowledge they use 'aspects' by placing that logic inside the setters and getters.
• The schema describes the contract between asp.net and the host and the asp.net and the front end like the device that it displays on.
• The adapter reads the schema and presents it in a friendlier way. The CodeSmith studio is an IDE for doing this. It has adapters that takes anything that presents a collection (e.g. a database), then for each table in tables - generate the code.
• The easiest way to jump into code generation it is to use the strongly-typed collection classes that comes from CodeSmith - accounts in ArrayLists should become an accounts object - it allows you to simulate the behaviour of generics now.
• Any time in the schema with max-occurs unbounded - we know it is an array and autogenerate a strongly-typed object it.
• The business people edit the XML in XML spy. Corillian separate domain objects from the message. They have a WSDL explorer. They use WSDL and a custom binding to generate the whole banking services. The proxy is generated from the WSDL - binds domain objects, messages and verbs.
• In future they are looking at using schematron that describe restrictions (e.g. saying something is an integer is not the same as saying it is a social security number). The intention is that the attribute on an element in the schema maps through an attribute in .NET.
• Scott's belief was that anything in the schema should be carried forward because the metadata should not be lost.