With prior versions of PostSharp, you had to be very careful to make your software compatible with any obfuscator. You could not obfuscate aspect classes, you could not store reflection objects, and you could not add use a reflection object in RuntimeInitialize with obfuscated generic methods. Indeed, all these features caused PostSharp to store the name of the metadata objects at build time, and to deserialize it at run time. But since the obfuscator renamed metadata objects after build time, the deserialization failed. Briefly said, previous versions of PostSharp were incompatible with all obfuscators.

PostSharp 2,1 provides a mechanism through which assemblies can be “repaired” after they have been obfuscated. Assemblies are still fully obfuscated, but PostSharp provides a utility to repair the name-object table. The build process is the following:

1. The compiler produces an assembly.

2. PostSharp post-processes the assembly and embeds an name table in the output assembly.

3. The obfuscator renames metadata objects, therefore breaks the PostSharp name table.

4. The post-obfuscation step (implemented by PostSharp) repairs the name table based on the obfuscation map produced by the obfuscator, and mapping the old name to the new name.

Since the post-obfuscation utility works with the obfuscation map, we need one implementation of this utility for every obfuscation map format, therefore for every obfuscation tool. PostSharp 2.1 includes support for Dotfuscator, the leading obfuscator .NET.

Calling the post-obfuscator

Let’s see how it works practically. You can download the example and try yourself.

To call the post-obfuscation step, you have to create an MSBuild project file and import the targets AddIns\PostSharp.AddIn.PostObfuscation.targets.

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">

  <ItemGroup>
    <!-- Required: Path of dependencies of obfuscated assemblies. -->
    <ObfuscatedSearchPath Include="Dotfuscated" />
    <!-- Required: Path of dependencies of unobfuscated assemblies. -->
    <UnobfuscatedSearchPath Include="Unobfuscated"/>
    <!-- Required: Obfuscation map file produced by Dotfuscator. -->
    <MapFile Include="Dotfuscated\Map.xml"/>
    <!-- Required: Obfuscated files -->
    <ObfuscatedAssembly Include="Dotfuscated\*.dll"/>
    <ObfuscatedAssembly Include="Dotfuscated\*.exe"/>
    <!-- Optional -->
    <ContentFiles Include="Unobfuscated\*.config"/>
  </ItemGroup>

  <PropertyGroup>
    <!-- Required: output directory -->
    <OutputPath>$(MSBuildProjectDirectory)\Remapped</OutputPath>
    <!-- Required: selection of the remapping strategy -->
    <Obfuscator>Dotfuscator</Obfuscator>
  </PropertyGroup>


  <Target Name="Build" DependsOnTargets="PostObfuscationRemap">
    <!-- Optional: copy other files to the output directory-->
    <Copy SourceFiles="@(ContentFiles)" DestinationFolder="$(OutputPath)"/>
  </Target>

  <Target Name="Rebuild" DependsOnTargets="Clean;Build">
  </Target>
  
  <Import Project="..\..\Build\bin\AddIns\PostSharp.AddIn.PostObfuscation.targets" />
</Project>

 

As you can see, this file defines some locations (required items and properties), and calls the PostObfuscationRemap target defined in PostSharp.AddIn.PostObfuscation.targets.

Safe code references

The post-obfuscator ensures the following references to code are repaired after obfuscation:

  • References you are not aware of (used by PostSharp to provide the runtime features).
  • Reflection objects (for instance MethodInfo, Type) serialized inside objects using the default serializer (BinaryFormatter). This feature is implemented thanks to serialization surrogates for reflection objects.

There is no magic. Other strings referencing to a metadata element, and stored somewhere else than in a reflection object serialized by the default serializer, will not be fixed. If you wrote your custom aspect serializer and want to take advantage of metadata reference serialization, you have to play with IMetadataEmitter/IMetadataDispenser.

In other words, if you want to write obfuscation-safe aspects, the only serialized metadata references should be reflection objects in an aspect field (or somewhere under an aspect field).

Stripping of events and properties

Dotfuscator allows users to remove events and properties from code. The reason is simple: they are useless at runtime for the CLR. They are pure compiler syntactic sugar… or rather were, before XAML. So what if your aspect stores a PropertyInfo or EventInfo?

PostSharp will be smart enough to provide you with a PropertyInfo or EventInfo. The only visible difference is that the Name property will return null. Other properties and methods will work as usually. Under the hood, PostSharp will give you an object of type ObfuscatedPropertyInfo or ObfuscatedEventInfo instead of RuntimePropertyInfo or RuntimeEventInfo, but your code should not see the difference.

Support for other obfuscators

As a first step, we provide support for Dotfuscator. If other vendors are interested to support PostSharp, we’ll gladly provide them with the specification of the binary format. If you want to contribute a post-obfuscation filter, then be pleased that the Dotfuscator-specific code is only 56 lines long (parsing of their XML obfuscation map). The post-obfuscation add-in is not obfuscated so feel free to use a decompiler :).

Summary

That’s it for obfuscation. A small, unexciting feature, but people who need to obfuscate their applications don’t have any excuse not to use PostSharp!

Happy PostSharping!

In my previous post, I introduced the new class ReflectionSearch and two of its methods: GetCustomAttributesOfType and GetCustomAttributesOnTarget. These methods give access to PostSharp’s internal repository of custom attributes.

Today, I would like to cover the second feature of ReflectionSearch: querying the relationships between elements of code. Three kinds of relationships are supported:

  • type inheritance (classes and interfaces),
  • usage in statements (a type, method, or field is used inside a method body),
  • member type,
  • any of the above, but as a type element (described below).

Navigating Type Inheritance

The system reflection API makes it easy to navigate from a child class to its parents, but the opposite is not true: if you want to retrieve all classes implementing a given interface in the assembly, you have to enumerate all types in this assembly, then enumerate all implemented interfaces, and do a recursion on the parent type. As was the case in the previous post with custom attributes, PostSharp indexes the type hierarchy for internal use. From PostSharp 2.1, ReflectionSearch exposes this feature to high-level aspects, and it comes with no performance cost.

The method ReflectionSearch.GetDerivedTypes does what it says, with one remark: by default, it returns only first-level derived types, i.e. it does not return derived types of derived types. If you want a deep search, you have to specify the option ReflectionSearchOptions.IncludeDerivedTypes.

Note that the method does not return an array of types, but of TypeInheritanceCodeReference. This object provides information about the base type. You may think the base type is always what you passed in the argument, but it isn’t always true. Consider the following code:

class GenericCollection<T> : ICollection<T> {}

class IntCollection : GenericCollection<int> {}

TypeInheritanceCodeReference[] derivedTypes = 
ReflectionSearch.GetDerivedTypes( typeof(ICollection<>);

 

In this case, GetDerivedTypes would return two pairs: (GenericCollection<T>, ICollection<T>) and (IntCollection, ICollection<int>). In each case, the base type is a different instance of the generic type.

Navigating Usage

As a part of the post-compilation process, PostSharp scans all method bodies and builds a bi-directional map of using/used-by relationships, i.e. it determines which fields, methods or type are used in statements and expressions of a method body, and creates an index. This functionality is now available inside PostSharp.dll and is exposed on two methods:

  • ReflectionSearch.GetDeclarationsUsedByMethod returns the set of fields, methods and types used by a given method.
  • ReflectionSearch.GetMethodsUsingDeclaration returns all methods using a given field, method, or type.

As you can note, it is not possible to query references to properties and events. Indeed, properties and events are compiler “syntactic sugar” and are never referred to by instructions at MSIL level. If you want to query properties or events, you have to query each accessor separately (add, remove, get, set).

These methods return an array of MethodUsageCodeReference. This object contains both ends of the relationship, as well as a bit mask telling which instructions the declaration was used with – so you can distinguish between a get or a set operation on a field.

Navigating Member Types

The last thing you can do with ReflectionSearch is to get a list of all members of a given type. By member, I mean a field, a property, an event, a parameter, or a return-value parameter.

This feature is exposed on ReflectionsSearch.GetMembersOfType.

Note that PostSharp does not use this feature internally, so there is an additional performance cost in calling that method. The first time you invoke GetMembersOfType, the assembly will be scanned and indexed (using PostSharp’s internal APIes, not System.Reflection).

Type Elements

By default, all methods of ReflectionSearch match the exact type passed as an argument (or match derived types if ReflectionSearchOptions.IncludeDerivedTypes is specified). However, there are cases where you want a larger choice.

Consider the following code:

class Bar {}

class Foo : ICollection<Bar>
{
   Bar[] array;

   void ICollection<Bar> FooBar()
   {
     return new List<Bar>();
   }
}

var derivedTypes = ReflectionSearch.GetDerivedTypes( typeof(Bar), options );
var members = ReflectionSearch.GetMembersOfType( typeof(Bar), options );
var usages = ReflectionSearch.GetMethodsUsingDeclaration( typeof(Bar), options );

 

With the default value of options, the three methods return an empty set. Indeed, there is no type derived from Bar, no field or return value of type Bar, and no instruction using Bar. However, if you include the option ReflectionSearchOptions.IncludeTypeElement, you will get:

  • as derived type: Foo,
  • as members: the field array and the return value of FooBar, and
  • as usages: the method FooBar.

The IncludeTypeElement option asks PostSharp to index at a much deeper level. Pay attention: this comes at a performance cost. PostSharp does not use this feature internally, so the first time you use the option, it will have to scan all type signatures and build an index.

Summary

The new ReflectionSearch class allows you to make complex queries over System.Reflection. Most of the times, the features are already used internally by PostSharp, so they come at minimal performance cost.

The ReflectionSearch class is accessible at build time only. The primary use case is to write more powerful logic for IAspectProvider or MethodPointcut. The second use case is to validate your code. And this is for another blog post.

Happy PostSharping!

-gael

One of the breaking innovations of PostSharp 1.0 in 2005 was the ability to execute aspect code at build time. Whereas other AOP frameworks developed complex declarative syntaxes to express “pointcuts”, PostSharp just allowed you to use System.Reflection to select the target of aspects. LINQ made it even easier to express complex code queries.

Yet, some queries were difficult to achieve just with System.Reflection. For instance, it is fairly difficult and inefficient to get all properties annotated with the [DataMember] custom attribute: you have to enumerate all types (and do a recursion on nested types), get all properties of these types, and check the presence of this custom attribute on all properties. Wow. If we were querying a relational database, we would probably create an index on the Type column of the CustomAttribute table. Well, the analogy is not so stupid. Metadata in a .NET assembly is in fact a relational database, and there is a CustomAttribute table. What is more, PostSharp already builds these indexes internally. So why not making them available to user code? This was the principal idea behind this new feature: reflection search.

Reflection Search is simply this: a set of methods making it easier and more efficient to query metadata of the assembly being processed by PostSharp. Therefore, this API is available only at build time.  It is not intended to “improve” System.Reflection for run-time use. That said, if you need to do some complex reflection query at runtime, it’s better to do it at build time using PostSharp, serialize the result and store it as a managed resource.

The API is exposed in the class PostSharp.Reflection.ReflectionSearch. Note that the feature is available in the Professional Edition only.

Enumerating Custom Attributes

Custom attributes of a type

The first set of methods you will find on the ReflectionSearch class allow you to enumerate custom attributes. GetCustomAttributesOnType retrieve all custom attributes of a given type in the current assembly (remember that this works only at build time, so the notion of “current assembly” refers to the assembly being processed by PostSharp). The second overload takes an additional parameter ReflectionSearchOptions. If you specify the value IncludeDerivedTypes, you will get all custom attributes of the specified type or any type derived from it.

There is no example in the system class library to illustrate a hierarchy of custom attributes, so let's create our own:

// A hierarchy of custom attributes.

class FruitAttribute : Attribute {}

class AppleAttribute  : FruitAttribute {}

class OrangeAttribute : FruitAttribute {}

class VegetableAttribute : Attribute {}

class TomatoAttribute : VegetableAttribute {}

// Using the custom attributes

[Fruit]
class Team
{
   [Apple]
   Dude tom;

   [Orange]  
   Dude jerry;

   [Tomato]
   Dude donald;

}

// Enumerating the custom attributes (build-time)
class MyAspect : AssemblyLevelAspect, IAspectProvider
{
 
    public IEnumerable ProvideAspects(object target)
    {

      CustomAttributeInstances[] attributes = ReflectionSearch.GetCustomAttributesOfType( 
typeof(FruitAttribute), ReflectionSearchOptions.IncludeDerivedTypes ); // TODO: Do something with that. } }

 

The method GetCustomAttributesType will return three instances of the custom attribute: (FruitAttribute, Team), (AppleAttribute ,Team.tom) and (OrangeAttribute, Team.jerry).

If you wonder why the method does not return a tomato: it is by decision of the U.S. Supreme Court, which, on May 10, 1893, declared that tomatoes are vegetables because – although they are classified as fruits in botany –  they are usually served with dinner and not dessert. As far as I am concerned, I still don’t eat tomatoes for dessert, the only thing that changed is that we are now much more accustomed to bureaucracy (and today’s tomatoes have better resistance to pressure because the species were selected to accommodate mechanical picking, and long storage and transportation – so arguably we now eat more tomatoes than in the XIXth century, but they are probably less tasty).

Anyway.

Note that the method returns a CustomAttributeInstance, which includes information about the custom attribute and the element of code to which it is applied.

Multicast attributes

Keep in mind that ReflectionSearch reflects the internal repository of custom attributes. This repository does not only include custom attributes that you add to your code manually. It also includes all “pseudo” custom attributes added by different components of PostSharp, starting with multicast attributes (remember that aspect class typically derive from MulticastAttribute).

When you use multicast custom attributes in your code, PostSharp executes the multicasting algorithm to populate the internal repository. The repository then contains the concrete instances of the custom attribute.

Let’s take an example:

[MulticastAttributeUsage( MulticastTargets.Method )]
class FooAttribute : MulticastAttribute {}

[Foo]
class MyClass
{
   void MyMethod() {}
}

In that case the repository contains an instance of FooAttribute on MyMethod but not on MyClass. The normal reflection API would give the opposite result (at least when it is run inside PostSharp or before PostSharp), because it is not aware of multicast semantics.

Since you can’t use normal reflection to retrieve multicast custom attributes, ReflectionSearch offers a second method: GetCustomAttributesOnTarget. As the name suggests, it returns the list of all custom attributes on a given element of code.

Summary

The high-level library PostSharp.dll now offers access to the internal repository of custom attributes. Since this repository, and all indexes, are used by PostSharp itself, using this new feature has minimal impact on build time. Now, you have a way to query custom attributes by type without killing performance. And you are finally able to query attributes that were created by PostSharp as the result of the multicasting algorithm.

But that’s not all ReflectionSearch has to offer. Next in line: browse relationships between elements of code. But this is for another day.

Happy PostSharping!

-gael