In the previous post the fun of enhancing assertion messages, I eluded about CciSharp… but what is it really?

CciSharp is a post-compiler framework for .NET. (In a sense, it is just a sample of things that can be done with  Common Compiler Infrastructure (CCI) ). CciSharp was designed with the following idea in mind: enable to easily write assembly mutators and integrate them into the build. In that sense, CciSharp provides

• A minimalistic layer on top of the CCI mutable source model.
• Provide the MSBuild ‘plumbing’ to integrate into a build so you don’t have to worry about it.

Do you have some Mutators examples?

Are you wondering the kind of problems can you solve with a post-compiler? Let’s take a look at a bunch of example (the full source of those samples is available at http://ccisamples.codeplex.com):

• Lazy Property: A lazy property computes its result once and caches it. Since it is not supported out of the box by C# or VB.NET, it requires boiler plate code to implement it. I’ve written mutator that takes a property makred with a [Lazy] attribute and implements this pattern. Here’s an example before and after of a property that returns the Environment.TickCount.
  
• Weak Lazy Property: The way we cached the property result above has a dangerous side-effect: it bloats your memory. Instead of storing the result has a ‘hard’ reference, one can use a WeakReference instead. That way, the GC can reclaim the cached references whenever memory pressure becomes too high (the GC is really a great built-in caching mechanism in .NET). Again, it takes a bunch of boiler plate code to implement this pattern, which is generated automatically by the another CciSharp mutator. Here’s another before/after example:
  
• ReadOnly Auto Property: Auto-properties are a great feature of C# but somehow I miss the ‘readonly’ keyword. The best that C# gives us is an auto-property with a private setter, which is not quite the same as ‘readonly’ fields. CciSharp contains a mutator that, given an auto-property with a getter and private setter,  (1) deletes  the setter, (2) makes the backing field readonly and (3) updates all the calls to the setter to direct access to the backing field. That way I get exactly what I want: a truly readonly auto-property. The snippet below shows the before/after transformation.
  
  

Those are a couple scenarios that tools like CciSharp enable. In the next post, we’ll look at the DependencyProperty pattern and how CciSharp can really help there.

HAPPY NEW YEAR!!!!