Lambda Expressions in T4 Templates

Despite being quite well hidden, Visual Studio's T4 templating engine is a great feature.

However, whilst putting together a T4 template in Visual Studio 2008, throwing in a simple lambda expression such as:

<#=string.Join(",", aList.ConvertAll(field => field.Name).ToArray())#>

Can cause the code generation to fail. As it turns out, the T4 template language is set to C# 2.0 by default.

This can easily be fixed by changing the template directive at the head of the template file to C#v3.5:

<#@ template language="C#v3.5" hostspecific="True" #>

Ideally this would be the default in a C# 3.5 project, but I'm sure there's a reason for this...

Visual Inheritance With .NET Compact Framework

The idea

Recently I've been working on an MVC framework for the .Net compact framework, partly to aid the re-use of certain visual components, such as signature capture screens etc.

As visual inheritance has been supported for the compact framework from VS2005 this should make it very easy to provide a nice base implementation that can then be customised as required.

To this end I created a simple base frame to handle some common functionality and a number of input frames to handle different tasks.

The Problem

At this point the input frames had text overlaid on them in design mode:

Visual inheritance is currently disabled because the base class references a device-specific component or contains p/invoke

Annoying, as I wanted the design time support of being able to visually edit the frames as required.

The Solution

Initial research turned up an MSDN article that discussed this issue and mentioned a number of causes including P/Invokes and device specific code.

The article also states:

If you are sure that platform invoke will not be executed during design time, you can safely enable visual inheritance by putting a DesktopCompatible(true) attribute on the parent form or the parent user control.

This attribute can be applied in a DesignTimeAttributes.xmta file (added through the add file to solution dialog):



true

And...it still failed. 10 more minutes off hair pulling and I realised that fraLogin inherited from BaseFrame, so I added the attribute to that class too:


true

And now visual inhertance works!

Summary

So in short, if you want visual inheritance when developing with the compact framework, remember to add the DesktopCompatible attribute to any controls that will be derived from.

Visual Studio 2003 And Find In Files Under Vista

It's probably widely known by now that Microsoft do not support Visual Studio 2003 under Windows Vista (and 7).

I still have to support a legacy application that was produced with VS2003, so decided to give it a go anyway. To my surprise everthing in the winforms application that I needed basically worked, including debugging, intellsense and so on.

Everything that is until I tried to use 'Find in Files', which promptly crashed Visual Studio.

The Fix

Until that happened, I didn't realise that I use this feature so much, but there is a relatively straight forward fix; by editing the compatibility settings of Visual Studio 2003 and adjusting the following:

  • Run program in compatibility mode for XP SP2
  • Disable Visual Themes
  • Disable Desktop Composition

Alternatively you could go use Visual Basic 6, which is supported by Microsoft under Vista.

XML Deserialization InvalidOperationException

Just a quick one today...

I was asked to help debug an issue with XMLSerialization in .Net where the object graph would serialize fine, but on being deserialized a InvalidOperationException was being thrown.

The class that caused the problem was defined in the following way:


public Class MyClass
{
public int MyInt { get; set; }
public DateTime MyDateTime { get; set; }

public MyClass(DateTime aDateTime)
{
MyDateTime = aDateTime;
}
}

This was nested inside another class in a collection, which initially I thought could be something to do with the problem. It turned out however that in order for deserialization from XML to work, each class that is to be deserialized must have a default constructor so that an instance of the class can be created by the XML deserializer.

This is easy to forget as the C# compiler implicitly adds a default constructor when there are no constructors in a class, but as soon as you add a non-default constructor, this goes away.

Simply adding


public MyClass(){}

Was enough to solve the problem.

The binary formatter does not suffer from this problem, although classes must be marked with the [Serializable] attribute.

Concise Invoking into the UI Thread

It's a new year (and has been for a while), so time to get on and actually make use of this blog.

I often find myself having to Invoke execution back in to the UI thread, and thus far the most concise way I have come accross for doing this is as follows:

public void UIFunction(string aMessage)
{
MethodInvoker del = delegate{
lblUILabel.Text = aMessage;
};
Invoke(del);
}

This is nice as it gives you access to the function parameters inside the Invoked anonymous delegate without needing to add them to the invoke call, and also saves you from creating any more functions, whose only purpose is to deal with being invoked.

Obviously you may want to consider that anyway if the logic is complex, but I like that this method keeps things nicely encapsulated in a single function.

The MethodInvoker delegate comes from the Windows.Forms namespace, so if you want to use this method where it is unavailable, such as on the Compact Framework, simply create a new delegate type as follows:
public Delegate void MethodInvoker();