Microsoft TechDays 2012 Finland ADM Materials

For both the T4 session and ADM session, the material is available as described below.

UPDATE 11.3.2012: Added the presentation slides (Finnish language).

Visual Studio T4 Code Generation from Ground Up (Finnish PDF)

ADM – Architectural Level Automation (Finnish PDF)

All the demos are maintained in the dedicated Git-repository at GitHub:

… or through git directly:

git clone git://

The development-centric roles are specified under the overview:

Categorized videos can be found here:

Current downloads are available through:

Note! The videos and downloads are CTP-level examples of what ADM can do. As we were aiming to business based ecosystem that is getting to CTP-stage as well, I didn’t update the examples or videos to any mid-release-stage material.

The high-level ecosystem overview is described here (including the infrastructure details for Git-based distribution):

For up-to-date status and especially resolving the ongoing issues the best way is to post to the Google group:

Thanks for everyone who attended at T4 session yesterday and welcome to the ADM session today!



This entry was posted in Computers and Internet. Bookmark the permalink.

3 Responses to Microsoft TechDays 2012 Finland ADM Materials

  1. Axiomatic says:

    The presentations were great with lots of ideas that seem very useful! I especially like the way all the abstractions and transformations are text files and thus manageable in version control.

    Based on the presentation and this site you seem to have plans beyond the obvious application (automatization of CRUD and service interface skeleton implementations) which I found curious. I admit the slight potential for an actual paradigm shift but have a hard time thinking of good practical examples of how this methodology can be successfully applied to the development of core functionality / business logic of a complex system. Although you correctly point out on this site that production reference implementations aren’t really necessary to demonstrate the basic concept, I feel they are necessary for demonstrating how the methodology can be effectively utilized in this DSL-like fashion.

    Question on more practical level: I didn’t read everything on the site yet so maybe this has been answered already but how are you supposed to organize the abstractions, transformations and generated code in a large multi-solution project with single abstraction definition potentially generating 10-15 files? Even with just tens of object definitions (each resulting in the 10-15 code / definition / script / etc files) just throwing them all in a single folder becomes hard to maintain.

  2. kalleabs says:

    Happy to hear that you found the presentations useful! It was a challenge to balance between hands-on demonstrations and connecting that to potential. As you properly also point out, concrete examples on this field are needed. We are working on these, when the final ecosystem infrastructure is realizing.

    To address your multiple-file-output question; it isn’t answered clearly in these pages. This demonstration is bit outdated (made on last summer), but it does generate Java-classes for Android serialization. Java as a language requires every class on its own file and filesystem structured for namespace. Hence the generation must also structure its files accordingly.

    The paradigm shift as I see happens “unnocited”. You only automate the portions where you gain the benefit. If you overautomate something (that is, working with automation is more troublesome than its worth) you simply stop using the generation. Properly done, your generators simply replace “reference-manual-implementation”.

    To bind this to “multiple-Java” generation, there are several ways to achieve the connection between automated and manually written. I’ve personally favored an approach where the distinction is clear through separate “logic implementation” classes that the generated code calls for. It means in Java that the generator can generate code on the same filesystem structure where the manual code is written. In such a case the generated classes need to be intentified from manual and this is simple to do with naming convention. The automation generated classes can have suffix such as “AbsGen”, which then of course needs to be in the filesystem names as well. Then the automation build process simply deletes all the files with that suffix before regenerating new ones (so that if any classes have been removed, they’re properly gone in the automated implementation as well).

    I’m happy to share the ecosystem and shared application modules details that concrete the modular reusability, in case you’re interested. We’re doing our best to openly promote the methodology, so any question posted on the Google group is dealt with as concrete example as possible.

  3. Pingback: Referencing a Code First DbContext from a T4 template? | Yaegle Answers

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s