Introduction Since my initial experimentation with generating project metadata data using T4 (Text Template Transformation Toolkit), there have been several obvious opportunities to expand its scope. One such opportunity has been to use T4 to generate static properties representing XAML keys. This serves to reduce the reliance on string literals when referencing resources. I have subsequently augmented my MetadataGeneration.tt template to do just that. x:Key Property Generation To demonstrate, I have updated the sample application...

This article is an elaboration of my previous experimentation with T4 (Text Template Transformation Toolkit) and describes how to use T4, which is built into Visual Studio 2008, and the Visual Studio automation object model API, to generate member and type information for an entire project. Generated metadata can then be applied to such things as dispensing with string literals in XAML binding expressions and overcoming the INotifyPropertyChanged property name string code smell, or indeed...

I am rather excited to share with you something that I have been working on in my spare time for the last couple of days. I have used T4 to build a metadata generator for your Silverlight and Desktop CLR projects. It can be used as a replacement for static reflection (expression trees), reflection (walking the stack), and various other means for deriving the name of a property, method, or field. There has been much...

Features Desktop and Silverlight CLR compatibility Capability to perform assignment and raise appropriate events before and after assignment. Weak referenced Provides for both expression tree and loosely typed strings Uses extended EventArgs to supply before and after values Extended PropertyChangingEventArgs for cancellable changes Configurable to use caching of EventArgs to decrease heap fragmentation Comes with unit tests for Desktop and Silverlight CLRs Introduction INotifyPropertyChanged is a ubiquitous part of Silverlight and WPF programming. It is...

Introduction It is generally considered good form to define a separate ServiceContract interface for all WCF services. By doing so, it decouples the contract from the implementation. Still, if we consume a service contract via conventional means such as generating a proxy using a ChannelFactory or using a ServiceReference generated proxy, we couple the service with the WCF infrastructure. So what could be wrong with that? Well, say if we have a local version of...