Why is post-compilation code injection a better idea than pre-compilation code injection?

Question

So we all know that C# doesn't have a C-like macro pre-processor (and there's a good thread on why here). But now that AOP is gaining traction, it seems like we're starting to do stuff with post-processors that we used to do with pre-processors (bear in mind that I am only getting my feet wet with PostSharp so am perhaps off base).

I am a huge fan of attributes in C#, but if a pre-processor was left out for good reasons (which, as a former MFC user I still question but nevertheless accept) why is post-compilation code injection a better idea than pre-compilation code injection?

Plath

Answer 1

The reasons why I chose post-compilation when designing PostSharp 5 years ago are:

1. Language agnosticism.
2. MSIL has stabler specifications compared to high-level languages (which have non-trivial updates every second year).
3. Most of the time, MSIL is the level of abstraction you need when dealing with aspects. You don't need to know all the equivalent constructs (think f 'using' and 'try-finally').
4. Before 2008, nobody has succeeded in producing a decent C# compiler. The difficulties met by Mono were impressive enough, even if they have caught up now.
5. Dealing with binary seemed much faster than dealing with source code.
6. Dealing with a binary assembly makes it possible to execute it -- the assembly being processed can transforme itself. It was unheard before PostSharp Laos was first released.

That said, implementations of AOP for C/C++ are indeed a pre-compiler (WeaveC) and implementations in Java are a compiler extension (for the good reason that there are many OSS implementations of the Java compiler).

-gael

Northerner

I agree, personally for you it makes perfect sense. However, none of the companies I worked for could adopt PostSharp for a single reason - non standard extra step in assembly compilation making it virtually impossible to integrate into more complicated process than just a simple one. – Farandole

Answer 2

Technically, there is a pre-compilation option for C# built into Visual Studio: The Text Template Transformation Toolkit (T4). This allows you to do pretty amazing things in a pre-compilation step, and is the basis of quite a few products, such as some ORMs, etc.

Shawntashawwal

You know, I've never looked into those. I should finally get around to that. – Plath

Answer 3

If you were to do pre-compilation you would have to interpret the source files from all the different languages you support then generate code in that language before it gets passed to the compiler. With post-processing you can simply use reflection to examine the assemblies whether the original language was C#, Visual Basic, or whatever.

Pervert

Along the same lines, I might add that code compiled in C# is compiled into MSIL (unless otherwise specified) which is still not actual machine code. It's JIT code. So, technically, what you refer to as "post-processor" is still actually pre-processor since the code is compiled at run-time. – Kessler

@regex: yeah technically true, however in the context of my question the MSIL is a compilation unit the same way a PE is with C++ (well technically a .NET dll is still a PE but you take my point). – Plath

So cross language support as the main reason (see @nobugz below)? – Plath

I also agree with nobugz. It's easier parse and generate IL than C#. – Pervert

Answer 4

It is just simpler. IL is a heckofalot easier to parse than C# source code. And it is language agnostic.

Moores

A text substitution pre-processor wasn't left out of .net because it was hard to do; at least according to the Gunnerson post. Language agnosticism I can buy however. – Plath

That wasn't my point, a preprocessor will never be available. Which only leaves parsing and rewriting source code as an alternative. That's technically possible, but unpleasant. – Moores