- Peter on UML Tools Extensibility
-
My esteemed colleague Peter Provost – whom I consistently fail to convince that I’m not into process engineering ;-) - has the first in what I’m sure will be a very informative series on extending the UML designers in Visual Studio 2010 Ultimate Edition
- DTE and T4 - Better Together
-
A couple of folks out there have put together some really neat T4 templates that use the host-specific flag and then access Visual Studio's DTE object model to read state from other code in the project and use that as metadata for code generation.
Daniel Vaughan started out with a nice post on using DTE to explore the source constructs within your project using the CodeModel and thence using that data to introduce compile time strong-typing to WPF binding expressions.
To borrow Daniel's example, to switch from this weakly typed case
<StackPanel DataContext="{Binding Source={StaticResource Person}}">
<TextBlock >Name:</TextBlock>
<TextBox Text="{Binding Name}" />
</StackPanel>
to this strongly typed one which gives compile-time errors if you get the name wrong
<StackPanel DataContext="{Binding Source={StaticResource Person}}">
<TextBlock >Name:</TextBlock>
<TextBox Text="{Binding Path={x:Static Metadata:PersonMetadata.NamePath}}"/>
</StackPanel>
He then also talks about using the same technique to generate implementations of INotifyPropertyChange that are robust to refactoring without the problems of embedded strings or the performance hit of reflection. Code generation and declarative programming are often criticized for not having good support for refactoring, so it's nice to see a use case that actually helps support refactoring.
Daniel has now expanded this into a full article on The Code Project.
Last time, I talked about Colin Eberhardt's article for generating Dependency Properties from an xml file. Daniel's approach inspired Colin to go back and rework his example to use DTE replacing his external XML file with custom attributes on classes to simply add dependency properties like so:
[DependencyPropertyDecl("Maximum", typeof(double), 0.0)]
[DependencyPropertyDecl("Minimum", typeof(double), 0.0)]
public partial class RangeControl : UserControl
{
...
}
Very cool stuff.
- T4 and Silverlight in Visual Studio 2008
-
Colin Eberhardt has a nice article on The Code Project walking through using a small textual DSL encoded in XML to define a set of dependency properties and then using that as a data source for T4 to generate all of the necessary boilerplate code.
Apart from being intrinsically cool, he's also doing this in a Silverlight project, and he includes the small amount of special sauce needed to get T4 generation working in a Silverlight project inside Visual Studio 2008.
BTW, in Visual Studio 2010, T4 in Silverlight should "just work".
- ASP.Net MVC T4 Updates
-
Couple of newsworthy T4 links for the wildly popular ASP.Net MVC framework.
This one is from July but I hadn't spotted it - David Ebbo has a new version of his T4MVC set of templates for view generation.
Space Invader Zim (nice name) has a walkthrough of an extension to the standard templates that he's been working on.
- Peter Vogel on Code Generation
-
There's a fun interview with Peter Vogel on the subject of Code Gen on the ever-popular .NET Rocks talkshow. He's got a new code gen book coming out and in the interview he says he's going to have an "expansion pack" for the book to cover T4. Can't wait for that.
You can find the audio here and a transcript here.
- T4 Templates for SharePoint
-
For all you SharePoint heads out there,
Waldek Mastykarz has a couple of neat articles on generating some of the various config files that control a SharePoint instance using T4:
Visual Studio T4 template for SharePoint Solution (DDF)
Visual Studio T4 template for SharePoint Feature Definition (Feature.xml)
Generate your own SPBuiltInFieldId class
Enjoy
- WPF, DSL in Visual Studio 2008
-
Although data-binding to WPF is a feature of DSL Tools in Visual Studio 2010, that hasn’t stopped our vibrant community from hacking away to get results today with VS2008.
Have a look at this selection of posts:
Using WPF As The Designer Surface In DSL Tools
Provide an improved user experience to your DSL's
Both of these use a naked objects style of approach which is pretty similar to what we’re building in to the core libraries in 2010.
The last one is more appropriate for complex UI’s that don’t represent you domain model so directly and proposes putting a viewmodel in front of your model.
How to bridge the gap between DSL tools store and the WPF DataBinding system
- Tangible T4 Editor
-
I've been remiss generally in not blogging while we've been heads down on Visual Studio Beta1, but never more so than in respect of another T4 Editor that's recently become available.
The good folks over at Tangible Engineering have been releasing several versions of their T4 Editor for Visual Studio 2008 and now have released a shiny version for Visual Studio 2010 Beta1. How's that for speedy?
Under Visual Studio 2010 Beta1, you can find this T4 Editor by simply going to the new Extension Manager (find it under the Tools menu)
So for all you T4 fiends, you now have a choice of editors (in strictly alphabetical order)
| | Visual Studio 2010 Beta1 | Visual Studio 2008 | Visual Studio 2005 |
| Clarius Consulting | Soon, I'm sure. ;-) | Get it | Get it |
| Tangible Engineering | Get it | Get it | |
Keep on transforming those templates.
- DSL Tools 2010 Beta1 Launches!
-
Jean-Marc announced today that the latest new beta version of DSL Tools launched today hot on the heels of the recent Visual Studio 2010 and Visual Studio 2010 SDK beta releases.
The team is really proud of all the great features we're shipping in this release. I hope you enjoy them too. From Jean-Marc's blog:
- Different models can now interact with each other, (and with Visual Studio Team System Architecture UML designers), using the ModelBus. A DSL author can choose to generate a ModelBus adapter, that will expose his model to other models or tools.
- Databinding support has been added, allowing Windows.Forms and WPF form-based designers to be created by binding a standard winform or WPF-based UI directly to DSL models. This enables developers to quickly create designers such as the .ResX or .settings designers in Visual Studio.
- It is now possible to have completely or partially read only models, which can be used for instance by reviewing and commenting tools.
- A number of UI enhancements have been added, including :
- moveable labels for connectors,
- sticky toolbox (when the user double-clicks on an item in the toolbox,it's not necessary to return to the toolbox for repeated applications of the tool),
- quick navigation and editing of compartments with the keyboard
- Copy and paste of diagram elements to images (in Bitmap and .wmf/emf)
- Copy and paste of model elements in or between diagrams
- The notion of DslLibrary has been introduced. This enables factorizing and componentizing DSLs (for instance having several domain models have the same base-domain class). The authoring for this feature will not be present in Beta1
- The DSLs can now be extended by third parties after they have deployment. The authoring for this feature will not be present in Beta1
Check out the Code Gallery page for samples and beta docs.
I'll start to list out in more detail the new T4 features after I get my breath back a bit. :-)
- Customizing Generated Resources in DSL Tools
-
Most of the code we generate with DSL Tools is pretty agnostic about its location or the filename you use for the template or the generated output.
The one exception to this is the generated resource file (usually a pair called DomainModelResx.tt/DomainModelResx.resx)
The reason this puppy is a little more sensitive is that the output resx is generated as item with a compile type of Embedded Resource in the Dsl csharp project that it lives in.
This causes the project system to pick up the relative path from the project root to the resx file and use that to form the Id that is used to embed the resource into the assembly.
Naturally, we also have to reference the resource at runtime in order to make use of its contents and to do that, we need to encode its Id at the point of use. This happens to be in the DomainModel.tt/DomainModel.cs pair.
What this means is that we have to provide some logic for generating that resource Id in our T4 templates as there isn't an API in Visual Studio to get hold of it :-(
Rather than trying to be too clever, we just use a simple scheme that expects the resource to be in the default GeneratedCode folder structure.
OK, that's all a bit abstract, so here's an example.
Given a normal folder structure like this:
You'll get a resource created like this:
You can see that the GeneratedCode folder name has been encoded into the resource Id.
We'll match that in the generated DomainModel.cs file with the following snippet
1: /// <summary>
2: /// The base name of this model's resources.
3: /// </summary>
4: public const string ResourceBaseName = "MicrosoftCorp.DemoLanguage.GeneratedCode.DomainModelResx";
So now suppose you go and rearrange your DSL project and now there's an intermediate directory called Dummy? And how about you also rename the template and generated file to be simply DslResources.tt/resx?
You'll get an embedded resource like this.
So far, this is all just regular VS stuff and not much to do with DSL Tools, but if we peek into DomainModel.tt/.cs, we'll see that the generated code has no idea that it has been moved and doesn't change that ResourceBaseName constant.
So how do we fix it up? We wouldn't leave you in the lurch now would we? No, of course not.
As an aside, we've done some work in DSL 2010 to let that directory change peek through into the template, but that doesn't help with the resource file name change.
To allow fine-grained control over matching the generated code path and resource name, we added three optional parameters to the DSL directive processor used in DSL Tools' .tt files:
- GeneratedCodeFolder: allow you to specify the folder relative to the project root where the generated resources live.
- GeneratedResourceFile: allows you to specify the filename for the resource base name
- ProjectDefaultNamespace: allows you to override the project file's default namespace as the starting point of the resource base name
Here's an example of using the first two to match up our project changes
<#@ Dsl processor="DslDirectiveProcessor" requires="fileName='..\DslDefinition.dsl';GeneratedCodeFolder='Dummy.GeneratedCode';GeneratedResourceFile='DslResources'" #>
We simply catenate the three values to form the overall base name, but keeping them separate allows us to reuse them in other scenarios. Here's the result, which matches the actual embedded resource:
1: /// <summary>
2: /// The base name of this model's resources.
3: /// </summary>
4: public const string ResourceBaseName = "MicrosoftCorp.DemoLanguage.Dummy.GeneratedCode.DslResources";
These extra parameters are pretty undiscoverable options on the DSL directive processor, so I hope this tip helps someone out. It's also a good example of how you can easily expand the directive processor we generate for you with your own DSL. These three parameters were all added purely additively in a partial class next to the generated code for the dsl directive processor. (Yes, we do generate the dsl directive processor that you use for parsing dsls to generate the directive processors for other dsls :-) )
Have fun rearranging your projects.
- Software Factories Redux
-
Don has a great post on where the p&p team are going with Software Factories and GAT/GAX.
No doubt we'll be talking to those good folks about how they can take advantage of new features in DSL 2010 in their 2010 versions of Factories.
- TellMe Voice Studio Beta1
-
I just noticed that the good folks over at TellMe (a relatively new bit of Microsoft) have shipped a beta of their Voice Studio voice application dev tool, based on DSL Tools. Very cool indeed! (I seem to be saying this a lot lately)
I love the process of developing voice apps - One of the last things I did in Microsoft before joining Visual Studio was to build a voice-enabled kiosk for helping folks access local government services. It was seriously rewarding when you managed to have testers use a natural seeming set of sentences to get something done. There's just a certain Star Trek magic to the whole process.
I think part of me may end up getting a similar buzz from extracting structured data from textual DSLs - MGrammar crossed with text extraction maybe - be interesting to go the same route as voice and have a confidence match for the textual DSL and then have a process of refinement from relatively vague textual musings to specific textual models.
Many congrats to the TellMe team (or as I'm steadily learning the colloquialisms over here, GO TellMe!)
- Clarius take T4 editing to the next level
-
I see that Clarius have now got to an alpha stage for the next stage of their T4 editing toolset.
As well as their Community Edition and Pro Edition, they're now going to offer a full-featured code generation environment they're calling Visual T4 Code Generator, including tight integration with server explorer, database tables and XML as well as a multi-file generation implementation out of the box and lots more beside.
Here's a short video of their database support:
Once again, very nice indeed.
- More on T4 in ASP.Net MVC
-
Abhishek from the MVC team has just posted some detailed instructions on using the new T4 customization features in the ASP.Net MVP release candidate
Very cool.
- T4 Adoption continues with ASP.Net MVC Tools
-
Ok, the big guns are pitching in now :-)
Hot on the heels of the tooling for LINQ-to-Entities folks adopting T4 for their next release, comes another.
Scott Guthrie just blogged about a new RC of ASP.Net MVC that will shortly be coming along. It's a long post, but down in the section on view templates in the scaffolding system, he mentions that they use T4 as a one-time generation technology to set these up based on your data.
Of course, this means that the generation is fully customizable.
I'm seeing the beginnings of a trend where product groups are finding they can get often-requested features for code generation customization by going the T4 route rather than hardcoding CodeDOM trees or some other tough to modify solution.
All isn't perfect, as of course this type of customizatio tends to require comparison of product and user templates when new versions of things come out. See Oleg's excellent encapsulation techniques (Nested Template Class especially) for ways to mitigate that.
