Using Expression when creating runtime types

In .NET 3.5, the framework provides the (greatly appreciated) mechanism to compile an expression tree to a delegate - providing a convenient way to write dynamic methods without having to dabble in IL (never pretty).

Over the weekend, I've been looking in more depth at the DLR trees in 4.0 (beta) - and an interesting little nugget leapt out at me... you can now compile an expression tree into the body of a MethodBuilder! This means that even when writing a full type at runtime you can write the methods using an object model rather than Reflection.Emit.

My current example of this doesn't really illuminate much, so I won't post it "as is" - probably to follow. But does this sound "time" for people having to learn how to use ILGenerator?

Don't get me wrong - expression trees aren't trivial, and you need to think carefully when writing them - but they are a lot simpler than writing IL directly.

Restricting attribute usage

.NET attributes are a great way of expressing metadata (when used appropriately), but I regularly see people frustrated that you can't have much control over when you can apply them. Sure, you can use [AttributeUsage] to limit it to any combination of fields, classes, properties, etc - but beyond that... nothing (unless you write an FxCop rule (hard work) or look at PostSharp (still hard work, and changes your build)).

I was looking at this today when somebody wanted to restrict the usage of an attribute just to members in a particular type (inheritance) hierarchy, and I trotted off the usual "sorry, you can't do that" response... but then I went and spoilt it all by proving myself wrong; actually, you can do this - using one of the rarer features in C# - protected classes.

In C#, you are only allowed to use the protected modifier (on a type) on a nested type - and the effect is that only types that inherit from the outer type (and the outer type itself) can see the nested type. And interestingly, it works for attributes! Here's the example I came up with:

abstract class MyBase {
    [AttributeUsage(AttributeTargets.Property)]
    protected sealed class SpecialAttribute : Attribute {}
}
class ShouldBeValid : MyBase {
    [Special] // works fine
    public int Foo { get; set; }
}
class ShouldBeInvalid { // not a subclass of MyBase
    [Special] // type or namespace not found
    [MyBase.Special] // inaccessible due to protection level
    public int Bar{ get; set; }
}

An interesting trick...

Checking your career path

or... have you asked yourself lately: "what matters to me?"

In July 1999, the Microsoft platform consisted of a combination of Windows 9x, NT4, SQL Server 7 (or 6.5 in most cases), and VB6 (more correctly, Visual Studio 6). Monitors were deep, storage wasn't, and there was still often a funny slot in the front of beige boxes to take the ever-rarer floppy disk. More importantly, though, I stopped scrounging as a student and started getting paid to write line-of-business code using that suite.

The thing is, though; I'm still at the same company, with just a snitch short of 10 years under my belt. Sure, I've changed job title a few times since then - but I've also repeatedly heard it said that it is atypical (unnatural, even) to stay in one place so long these days (a "job for life" being ancient history) - especially as a first job.

But why should I change?

• I like the work and the team, and the projects are ethical; and usually varied, interesting and rewarding
• The company* is big enough to span most of the common "enterprise" scenarios for IT systems
• They have always respected that I'm happy being a code geek; I'm quite good at it, and I don't particularly want to be a manager (indeed, over the last few years they've introduced an additional grade of senior geek**, to respect this as a career progression option)
• We're pretty good about adoption of new technologies and methodologies
• I'm still learning and growing, both in work and on my own time
• My employer is liberal about my out of work community involvement - indeed, they actively encourage and support such
• They are pretty flexible, with a number of policies that help with the fact that (by my own choice) I live a stupid distance away and commute by train
• The compensation package is acceptable
• The sector (education) is relatively stable and secure

(*=if you are UK-based and want to check the recruitment boards, it is no secret that I work at RM)
(**=no, that isn't the actual job title)

My only possible concern is that as a result, I've been mainly limited to the Microsoft technology stack. I can't really complain here, though since:

• The stack is rich enough and fast moving enough that you can never know all of it
• As part of the senior technical team, I'm involved in our choice of tools, so it is (in part) of my own doing

So why should I change?

Frankly, I have no immediate plans to do so. I do, however, firmly believe that it is critical to regularly check that one is following the right path. I think that with the above list I've done enough to satisfy myself that I'm still in the right place for me (and conversely, for my employer: a malcontent employee isn't a constructive employee). But have you asked yourself the same question lately?

Some history: I was guilty of this a few years ago; we (my wife and I) found we'd been idly "drifting" through life for several (wasted?) years. We only realised this (the hard way) when my father was tragically killed in an accident while on holiday; in the sad, reflective months after that, the question(s) came up "what are we doing? where are we going? what is important to us?" As it happened, it turned out that going to work each day to pay the mortgage wasn't actually our life goal - and we made some big changes (including relocating half way across the country) and went the family route. We've never been happier. Of course, you need to make your own priority list (and it doesn't strictly have to relate to career), but make decisions - don't just drift idly. And "no change" counts as a 100% valid decision, as long as it is considered.

Summary

Reminiscent of a project health-check...

Priorities weighed and measured? check
Remedial action? none required
Follow up actions? re-book in 1 year, same attendees

And back to the grindstone...

protobuf-net support for 2.1

I've finally found time to add support in protobuf-net for the changes in the main protocol buffers 2.1 release.

For those interested in a fast, efficient, portable (interoperable), obfuscation-safe, binary serialization engine for .NET, then this adds (among other things):

• "packed" encoding for lists/arrays/etc of simple types (int, float, etc) - much more efficient, as it avoids the need to send a field identifier per element
  
• the ability (in .proto definitions) to mark members as deprecated (maps to [Obsolete])

It also introduces a range of bug-fixes, enhancements etc in my own code (nothing to do with 2.1) - including better namespace control when performing code generation.

Probably the biggest difference between protobuf-net and the other implementations is that although you can do contract-first (via a .proto), it doesn't force you to do that - so you can either define you types in a .proto, or you can just use your regular .NET classes with a few attributes (it can even piggy-back of WCF [DataContract]/[DataMember] in many cases). This has always felt more natural to typical .NET development (at least, from what I see).

I'm guessing it'll be a few months before the core Google API changes again, so hopefully this will be the last release (except for very minor bug-fixes) in that branch; I'm still trying to refactor (read: re-implement...) the code to work around those pesky CF limitations (and improve the performance and quality in the process).

Fun fun fun...