T4 template for xsd2code

Mar 8, 2010 at 2:47 PM

Modify small xsd generated code by hand to meet your expectations is not very difficult, but if you have a big xsd it's really a pain.

T4 templates are great because leave the whole code generation in the hands of the developer, it's a full customizable code generation tool.

It would be nice if xsd2code could accept a T4 template as source and generate the code with it, here an explanation how to instantiate the T4 engine and process template to generate code.


It would be a great improvement for xsd2code.

Mar 8, 2010 at 9:04 PM

I don't know at the moment T4.
I'll watch. Thank you for this information.

Mar 10, 2010 at 9:27 PM

It would be pretty difficult to incorporate T4 Templates, which would require Language specific Templates ala ASP.Net. Xsd2Code is based on Xsd.exe which uses Language Independent CodeDom. CodeDom allows Xsd2Code to target multiple languages.  Granted we do have some Language and Framework dependent code: Automatic Properties is one such feature.

Mar 11, 2010 at 3:21 PM

It was just a suggestion, a checkbox with a textbox for advanced users who want to have more control on the generated code.

At the end you can't implement all the requested features and minor variation, for such purpose a T4 template is perfect.

Almost all the reported problems and requests could be resolved with a custom T4 template, so the users haven't to modify the generated code by hand or wait for a new release hopping that the bug has been fixed.

I was thinking to a standard T4 template for C#, VB.Net, C++, etc which can be modified in a textbox and saved together with the other options.


Mar 12, 2010 at 3:08 PM

I fully agree that Xsd2Code could benefit from a way to allow customization of the Generation process. The suggestion is well taken in that regard. The real issue is that T4 is a template engine like ASP.net and CodeSmith, Xsd2code completely relies on CodeDom to create a platform independent source code model.  Excuse me if you are already familiar with CodeDom, ( and you probably are ). The structure of a CodeDOM graph is like a tree of containers. Xsd2Code doesn't parse the schema it lets .Net produce the initial CodeDom graph. Xsd2Code walks the graph transforming the code.  It's not that T4 is a bad idea. It just would require a large amount of refactoring; bordering on a complete rewrite.

Further we would have to maintain multiple code bases for the T4 templates. Recently, I've worked very hard to remove as much Platform Dependent CodeDomSnippets replacing them more specific CodeDom types. Right now with a little effort we could Target any platform where there is a CodeDom Provider, Such as IronPython.

Having said that. You can download the code and look at where the initial CodeDom Model is built from the Schema ( Xsd2Code.Library.Generator.Process(GeneratorParams) in the region "Get XmlTypeMapping", and you could then use that generated model as the base objects for T4 or any other templating language of choice. This is where we would have to start and everything else would have to be completely reworked or even discarded. Pcabanel might have better opinion: He's the code owner.


Mar 16, 2010 at 8:59 AM

I know CodeDom and it has its advantage as you mentioned to generate code for different languages, the disadvantage is that the generate code isn't customizable. If you are like me, you will be agree that there is always something in generated code that you don't like, call them preferences, but you will be never satisfied with it. T4 engine gives you the power to generate your code, the disadvantage is that you need a T4 file in your project. I know that is language dependent but for advanced user is much better, it's like asking if you prefer a car with automatic or manual transmission? The common driver will ask for AT but a sport driver will prefer the MT because he want to have more control over the car/engine. CodeDom is the AT and T4 is the MT.

Mar 16, 2010 at 4:12 PM

I'm in full agreement on the reasons for T4 and am certainly not arguing against it or a vehicle to provide developers a way to customize the output. I'm just not sure how to do it, without a major rewrite of the current implementation. I know you looked it how Xsd2code is processing the CodeDOM.  How would you suggest it be done? Admittedly, I do this part-time and I have not focused on T4 and thus see Xsd2Code through CodeDOM colored Glasses :-).

May 12, 2010 at 6:44 AM

Look at http://t4toolbox.codeplex.com/ where Oleg already has a special T4 preprocessor for XSD.