As a conclusion to the series of articles which started with a discussion on the various ways one can perform simple validations on method parameters using PostSharp, I thought I’d share my final thoughts on the matter as well as what I’ll be ultimately using my in own environment.

My primary concern with the original solution has had to do with both the signature of the actual base validation method as well as how we should pass the parameters we’re validating to it. Specifically, I wanted to make sure that the solution wasn’t introducing an excessive amount of boxing into code, which was a valid concern given the weak nature of the validation method’s signature (i.e. the fact that the validation method accepts the parameter as a System.Object type).

What We Have So Far

First of all, the reason why this is even important is because of the potential widespread usage of  the validation method — if this is how we’re checking if something is null or not, then in we can expect a very large presence of such a method in a typical non-trivial application.

The original abstract validation method had the following signature:

public abstract void Validate(object target, object value, string parameterName);

The second parameter (value) represents the value of the parameter we’re validating, and it is the focal point of the topic at hand.

Let’s then go over some quick points that concern the implications of using a validation method with such a signature:

  • Because the parameter type for the parameter’s value is System.Object, and not a generic type parameter, parameters which are value types will need to be boxed before being able to be provided to the method.
  • Furthermore, if the parameter we are validating is a generic type parameter, then if at run-time that generic type parameter is substituted for a value type, that too will need to be boxed.
  • While emitting a box instruction while a value type (or generic type parameter substituted with a value type) is on the stack incurs the traditional performance penalty associated with boxing operations, doing the same with a reference type (perhaps originally a generic type parameter substituted with a reference type) on the stack is essentially a nop.
  • Because we’re weaving in raw MSIL here, we’re responsible for supplying the boxing instructions; this won’t be taken care of for us since the compiler is out of the equation…so we need to cover all these different scenarios.

My Approach and Strategy

After some review, I’ve settled on an approach in regards to what the validation method signature should look like as well as the strategy involving how we get the parameter value we’re validating to the method.

First of all, an ideal solution would be to not depend on a weakly based validation method, but rather make use of a validation method that accepts generic type parameters. While this would be cool, it’s actually not the most simple of endeavors. The generic type parameter can be defined on different levels (e.g. type vs method), and how do we call the method if we have no generic type parameter (i.e. the parameter we’re validating is a standard, non-generic type in its original form)?

Those different scenarios require you to do different things, and although I was able to pass some, I lack the inside knowledge of the PostSharp SDK to be able to cover all of them.

In the grand scheme of things, however, the approach I ultimately ended up using has proved to be more than adequate for the job. Given the body of work I’ve been involved with and the types of entities requiring validation, I found that the benefits that would be gained from the ideal solution to be extremely negligible in substance; therefore, it is the most justifiable approach when my own time is weighed as a factor in the equation.

The signature for the validation method ended up staying the same as it was originally. The type I am using for the parameter value remains System.Object. My strategy in regards to how I’m invoking the method is the following:

  1. If the parameter being validated is explicitly a value type, then it (of course) gets boxed before being passed to the validation method.
  2. If the parameter happens to a generic type parameter, then we only box it if it contains no generic constraints which guarantee the type substituted at run-time to be a reference type (e.g. a specific reference type or the class keyword).
  3. Furthermore, (further down the inheritance chain) any validation attributes which perform types of validations that only make sense when being conducted on reference types (e.g. NotNull) have built-in compile-time validation to ensure we it’s not being applied to any explicit value types.

The vast majority of parameter validations occurring in my main body of work are done on generic type parameters. Many times (though not always) these type parameters are constrained to be reference types. In the end, boxing almost never occurs, therefore this is quite acceptable to me.

To implement this strategy, I simply added a property named RequiresBoxing to the EntityDescription type I talked about in a previous article, which I set during the initialization of the EntityDescription object like so:

_requiresBoxing
  = entityType.IsValueType
    || (entityType.IsGenericParameter
        && !entityType.GetGenericParameterConstraints().Any(c => c.IsClass));

If, in the future, I ever found myself having to perform (let’s say) numerical-type validations on (obviously) value types, I’d probably create a separate class of validation advices which were specific in the value type being validated.

 

The Weak Event Pattern

Microsoft made a good move with .NET 4.0 when they introduced the concept of a weak event pattern as a technique meant to address a glaring WPF memory leak issue that had the tendency of arising under certain conditions. You can read all about it here, but that aside, it helps to actually understand the problem that merited the creation of these techniques.

Memory leaks arising from lingering event subscriptions is an often misunderstood issue. Remember, in a CLR environment, memory is managed by the CLR’s own automatic garbage collector. In this context, a memory leak refers to a nonoccurrence of the collection of one or more objects which otherwise should have been collected according to standard expectations. Thus, assuming that the CLR garbage collector is “perfect” (it is quite good), the notion of a memory leak occurring should be a foreign one. But it can happen, and one of the preconditions for that scenario has to do with event subscriptions.

It’s not as simple as the presence of lingering event subscriptions, however. Let’s go over some incredibly rudimentary terminology:

  • One object exposes events that other objects can subscribe to. This object is the publisher of the event.
  • The objects which attach handlers to the publisher are subscribers of the event.

Why It’s Needed

From the subscriber’s point of view, I should always be sure to detach all handlers previously attached to the publisher as soon as it is practical. In fact, this requirement makes me a good candidate for a purely-managed focused implementation of the IDisposable interface. However, if I, as the subscriber, shirk these responsibilities, we aren’t necessarily guaranteed a memory leak. It is only when the lifetime of the publisher exceeds that of the subscribers will we have ourselves a memory leak. This is more of a matter-of-fact observation than a deep deduction; because subscribers have handlers attached to the publisher, the publisher will maintain a reference to those subscribers, and thus those subscribers cannot be collected.

This becomes a problem, especially when the subscribers need to die. An example that can occur is when you have some type of collection view or view model that contains children views or view models. This collection publishes an event that its children subscribe to. Whenever a child gets removed from the collection, we would very much want that child to be collected, especially if it is something significant such as a graphical view. Unless that child’s handler is detached, however, this collection won’t occur.

Many times the objects involved will lack the level of intimacy with each other required for one to know that that it needs to tell the other that it needs to clean up its event handlers. One of the constructs Microsoft developed in order to account for situations where associated objects lacked understanding of the internal behavior and structure of each other was the IDisposable interface. Unfortunately, WPF makes little to no use of this approach, which I believe is both odd and a major cause of all of these problems. Therefore, implementation of this interface will do nothing for you and your WPF-specific objects.

How to Use the Pattern

Making use of the weak event pattern is a rather simple affair:

  1. Create a new manager class derived from WeakEventManager
  2. Create a new implementation of IWeakEventListener
  3. Wire up the IWeakEventListener appropriately

Although it is a simple few steps one must complete, it is a bit burdensome to have to create new classes for each event or group of events coming from a specific source which we want to listen to weakly. There is a heavy use of static methods involved with this pattern as well, further restricting our options in regards to inheritable functionality.

Why does the pattern require specific types defined for specific events? The answer has to do with performance. It is possible to create a generic WeakEventManager, but your performance will suffer. Indeed, with .NET 4.5, we will see a generic WeakEventManager introduced by Microsoft. However, with it comes the warning I just provided: use of the generic variant of WeakEventManager will result in decreased performance. The performance trade-off most likely has to do with reflection cost as well as expectations by internal WPF components and processes which may have been optimized around an expectation of discrete manager types.

A Generic IWeakEventListener

With IWeakEventListener implementations, however, the story is different. Here we can easily devise a generic variant which we can easily use without worry of performance implications.

Here is an example of a generic IWeakEventListener implementation:

WeakEventListener.cs 
/// <summary>
/// Provides a generic weak event listener which can be used to listen to events without a strong reference
/// being made to the subscriber.
/// </summary>
/// <typeparam name="TEventArgs">
/// The type of <see cref="EventArgs"/> accepted by the event handler.
/// </typeparam>
public class WeakEventListener<TEventArgs> : IWeakEventListener
    where TEventArgs : EventArgs
{
    private readonly EventHandler<TEventArgs> _handler;

    /// <summary>
    /// Initializes a new instance of the <see cref="WeakEventListener{TEventArgs}"/> class.
    /// </summary>
    /// <param name="handler">The handler for the event.</param>
    public WeakEventListener([NotNull]EventHandler<TEventArgs> handler)
    {
        _handler = handler;
    }

    bool IWeakEventListener.ReceiveWeakEvent(Type managerType, object sender, EventArgs e)
    {
        TEventArgs eventArgs = e as TEventArgs;

        if (null == eventArgs)
            return false;

        _handler(sender, eventArgs);

        return true;
    }
}

Using this generic variant is quite simple: add it as a member to a subscriber class, and make a call to an appropriate WeakEventManager.AddListener method in order to register the weak event listener from the subscriber during its initialization.

 

Recently I’ve been involved with creating a general purpose library (to be used at my company) that includes, among other things, a nice API for creating and manipulating Task Dialogs from .NET-land. As with everything unmanaged, implementing it not only yields the benefit of being able to use it, but you tend to learn some interesting things in the process.

Unable to find an entry point named ‘TaskDialogIndirect’…

It won’t take long until you run into this lovely issue. Shouldn’t be much of a surprise to anyone familiar with such matters, but, in case you didn’t know, the TaskDialog API is only available on version 6.0 and up of the Common Controls library (on post-XP of course…I think there’s also a v6 on XP, but it is different version nonetheless). If you’re running Windows Vista or 7, then you have this library installed by default, however it is the older version 5.8 of the Common Controls library that will be loaded by default.

We have multiple versions of comctl32.dll because of that libraries participation in the side-by-side assembly system, which was Microsoft’s answer to DLL Hell and somewhat of a precursor to .NET’s Global Assembly Cache. If we intend on having our .NET application load the correct version of comctl32.dll, then we’re going to have to participate in that system, which then requires us to provide a manifest dictating the version we need.

Providing a manifest is simple if your end-product is a .NET executable: you simply add an application manifest which will isolate the application and load the appropriate DLL versions at run-time; however, it is not as straight forward if you’re writing a .NET library, since simply embedding a manifest into the DLL exerts no influence at run-time on an executable referencing it. Specifically, the type of manifest we are talking about here is an application manifest (as opposed to an assembly manifest). Visual Studio offers support in the C# project properties designer for embedding application manifests into application projects, but not libraries.

Activation Contexts

Requiring that all applications referencing your library also include their own correctly-made application manifest if they want a specific subset of features provided by your library to work is an exceptionally unrealistic requirement. If we cannot automatically affect the run-time so that the proper unmanaged DLL’s are targeted, then we are providing functionality that is not guaranteed to work. As such, such functionality cannot exist in any proper library, and would have to be removed. Luckily, we do have the power to influence the run-time from the confines of a .NET DLL, and the way we do it is by making use of activation contexts.

By activating an activation context, we are essentially telling Windows to redirect the running application to a particular DLL version according to a manifest of our choice. In fact, activation contexts are the very engines that power the side-by-side assembly system. When an application needs to make a call to a library or create a process or other resource, Windows checks that application for the presence of an application manifest, using the information found in that manifest in order to populate an activation context to use to guide that call to the correct destination.

Normally, activation contexts are managed entirely by the Windows system; however, in our case, we’re going to be rudely intruding into that system so that we can perform some actions not taken by the Windows system. Specifically, prior to our P/Invoke call to TaskDialogIndirect, we’re going to create and activate an activation context that will redirect that call to the proper version of comctl32.dll. There is official precedence for this activity: the Windows Forms library does exactly what I’ve just described when you make a call to Application.EnableVisualStyles.

Microsoft provides some documentation on how we can do that from a managed environment in the form of a KB article. I’m not going to provide a complete walkthrough on the process here, as the KB article covers most of it, but I do want to address one of the limitations of the approach offered by that article. In particular, I’m referring to how the approach offered by the KB article requires that an actual manifest file be present on disk. Relying on an external non-binary file for something that shouldn’t be configurable by an end-user anyway is clunky and not desirable.

Luckily, we can do better than that. Instead of using a physical manifest file as a source for the activation context, we can create an activation context using a resource embedded in our DLL instead. And we can do all of this simply by configuring the ACTCTX structure populated during the process differently.

Activation Context Creation Using a PE Image Source

The application manifest can typically be found in the .rsrc section of a PE image, where it exists as a resource like any other. With Visual Studio, you can add an application manifest to your project (let’s call ours Library.manifest), and then enable the embedding of that manifest into project’ s output through an option located in the project properties designer. However, no such option exists for DLL projects, but this doesn’t matter since we can get Visual Studio to do what we want anyways. Open up your *.csproj file with the XML editor, and add the following to the first <PropertyGroup> in the file:

<ApplicationManifest>Library.manifest</ApplicationManifest>

This will result in your manifest file being embedded into the DLL compiled from your project. You will see that the manifest is embedded, not as a .NET resource, but as a true native resource of the RT_MANIFEST type. The resource ID of the manifest should be 2. This is the standard resource ID for all manifests found in DLLs. In fact, whenever a native DLL containing an embedded manifest resource with an ID of 2 is dynamically loaded at run-time, the operating system loader automatically creates an activation context using that manifest. It does this so it can then proceed to load all dependencies of that DLL without issue.

This obviously is not going to happen for our DLL, however, since this our DLL is a managed DLL, of course, and it is loaded a bit differently. Regardless of this, we still need our manifest embedded in our DLL so that it can be sourced appropriately by the activation context we are going to be creating.

Following this, we need to change some of the code you may have picked up from that KB article. Specifically, we need to populate the ACTCTX structure that gets provided to CreateActCtx a bit differently.

  1. The KB article sets the lpAssemblyDirectory to the directory containing the current assembly. Although the KB article is throwing terms like “security hole” at us in the nearby code comments, we’re actually going to remove this assignment, and leave lpAssemblyDirectory unset. I don’t believe this is documented anywhere, but in actuality, I believe the Activation Context API ignores lpAssemblyDirectory when loading the manifest in the way we are going to be doing it.
  2. Next, the KB article has us setting the dwFlags field to ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID. We actually want to set it to ACTCTX_FLAG_RESOURCE_NAME_VALID instead (which is 8, by the way).
  3. The provided example sets the lpSource field to the path of the physical manifest file. Since we don’t have one of those, and because our manifest file is embedded in our DLL, we actually want to set lpSource to the path to our DLL file.
  4. Finally, we need to tell Windows what the resource ID of our manifest is, and we provide that information by setting the lpResourceName member using MAKEINTRESOURCE.

The last step in the steps listed above requires us to set lpResourceName using a value that we derive from MAKEINTRESOURCE. While that’s not a very tall order when we’re developing in C++, how do we do this from a managed, C# environment? The simplest way is to actually change the return type for this field in our ACTCTX structure definition.

Looking at the KB article, the sample ACTCTX structure they provide looks like the following:

private struct ACTCTX
{
   public int       cbSize;
   public uint      dwFlags;
   public string    lpSource;
   public ushort    wProcessorArchitecture;
   public ushort    wLangId;
   public string    lpAssemblyDirectory;
   public string    lpResourceName;
   public string    lpApplicationName;
}

Change the return type of lpResourceName to an IntPtr (!!); yes, an IntPtr, so that we have the following:

   public IntPtr    lpResourceName;

And then, remembering that the ID for our manifest resource is 2, we can then populate our structure like so (substituting “ClassName” for the name of the class where this is being done of course):

ACTCTX context = new ACTCTX
                     {
                         cbSize = Marshal.SizeOf(typeof (ACTCTX)),
                         dwFlags = ACTCTX_FLAG_RESOURCE_NAME_VALID,
                         lpSource = typeof(ClassName).Assembly.Location,
                         lpResourceName = (IntPtr) 0x2
                     };

Providing this structure to CreateActCtx will then create a new activation context based on our embedded manifest. Well almost. Did you happen to create your application manifest using Visual Studio’s application manifest file template?

Fix Your Application Manifest

I found CreateActCtx to be extremely touchy when it comes to the actual form of the application manifest itself, and that the manifest generated by Visual Studio was utterly incompatible with it. Attempted to create a new activation context using a manifest like that would result in CreateActCtx returning an error code.

The manifest generated by Visual Studio contains a ton of XML namespace attributes which may or may not make CreateActCtx puke. I say “may or may not” because I’m not sure if it was these namespaces or another part of the stock manifest content that caused it to fail. But, that doesn’t really matter. Here’s a cleaned up manifest file that is guaranteed to work for you:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <noInherit/>
  <description>
    Your manifest
  </description>
  <assemblyIdentity version="0.0.0.1"
                    name="Your.Library"
                    type="win32"
                    processorArchitecture="*"
                    />
  <dependency optional="yes">
    <dependentAssembly>
      <assemblyIdentity
       type="win32"
       name="Microsoft.Windows.Common-Controls"
       version="6.0.1.0"
       publicKeyToken="6595b64144ccf1df"
       language="*"
       processorArchitecture="*"/>
    </dependentAssembly>
  </dependency>
</assembly>

You can add other sections, such as a <compatibility> section if you’d like, and they should work fine. Also, the <description> element is not required for this to work (hell, I’m not even sure if that’s a standard manifest element…all I know is that I’ve seen it in a number of in-use manifests originating from Microsoft). After you do all of this, it should start to work with CreateActCtx.

But hey…this is where the fun begins. You shouldn’t get the false impression from all of this that you can now go willy-nilly and be able to act foolishly without suffering consequences. I heavily tested my code and came across a few “edge” cases that you need to be very careful about, as you can easily cause issues when acting within one of these self-made activation contexts.

Who Doesn’t Love SEHExceptions?!

You know that when you’re getting structured exception handling errors in managed code, that you’re doing something very special. Now, before I go on, let me state that I tested my use of activation contexts very heavily and found them to be very stable. However, a factor allowing me to come to that conclusion is the fact that the code executing within the activation context is very stable. If your code is anything less than that, or if it is operating in an extreme environment, you probably want to exercise caution.

Through my testing, I did identify an issue that I do not altogether understand, due to the fact that the problem was occurring deep in unmanaged land, and I couldn’t come across much material relevant to my issue.

The problem I encountered was an interesting one. As we know, we’re dealing with Task Dialogs here. While the Task Dialog is open, the thread that opened it will be blocked until it is closed. Well, not entirely. While blocked, however, the same thread is going to handle any callbacks fired by the Task Dialog. Because we require an activation context to open the Task Dialog, the call to open the Task Dialog is done within a using block for the disposable class which handles the activation context creation and activation. When we hit the finally block of that using block, it’s going to make a call to DeactiveActCtx.

I found that if I threw an exception while handling a callback from the Task Dialog, that an SEHException would get thrown by DeactiveActCtx during the disposal of the class that created the activation context. The activation context would essentially become impossible to deactivate, indicating perhaps that somehow the activation context stack was corrupt. The error code for the SEHException was 0×80004005, or: External component has thrown an exception. Throwing an exception within the activation context, but not during the handling of a callback, would cause no problems when deactivating the context.

So…if anyone else has this issue, then I would advise to make sure the dialog is closed first before throwing the exception. My Task Dialog class has a Closed event, so I would simply schedule the exception to be thrown in an event handler for that, and then proceed to close the dialog from the callback. The context would deactivate with no issue, and the exception could then get thrown and thrown in the developer’s face.

 

With the release of .NET 4.0, Microsoft made some large scale changes to the framework’s security model. Concluding that the legacy model was little understood by both developers and IT administrators, Microsoft decided to do what is normally a very prudent action: they decided to simplify it.

In previous versions of the .NET Framework, the security model was tangible in the form of Code Access Security policies. Each policy was a set of expressions which used information associated with assemblies in order to determine which code group said assemblies belonged to. Each code group would contain a permission set, which would then be referred to by code access demands made in response to attempts to perform privileged actions.

.NET 4.0 got rid of all that nonsense with the introduction of level 2 transparent code (although technically, CAS still exists; what’s been eliminated is CAS policy). Basically, under this system, machine-wide security policy is off by default, and all desktop applications run as full trust. Code is either transparent, safe-critical, or critical; assemblies lacking annotation will have all their types and members treated as being critical if the assembly is fully trusted, or transparent if the assembly is partially trusted only.

Instead of worrying about having to make a bunch of strange security-related assertions and demands, all one needs to do to run under the new model is annotate their code appropriate using the three main attributes: SecurityTransparent, SecuritySafeCritical, and SecurityCritical. Sounds good; simple is better, but don’t use this new system. It isn’t ready for the real-world yet.

This article is not meant to actually criticize the substance of the new security model. I think the model is a huge improvement, but there’s a a few specific issues that cause me to view it as a mess as it now stands. Before we get into one of those issues, let’s look at reality first.

Most of the .NET Framework Doesn’t Use It

One of the ways I gauge the viability of new technologies from Microsoft is by trying to get a handle on whether or not Microsoft itself it. This approach has never failed me, and has saved me from a countless number of time sinks that would have affected endeavors both professional and personal. So, in order to check out the immediate viability of the new level 2 transparency model, let’s look at the primary .NET Framework assemblies and see whether or not they use it.

We can tell whether or not a particular assembly is using level 2 transparency by taking a look at the assembly’s metadata. If the assembly is operating under the level 2 transparency model, it would contain a SecurityRulesAttribute with a SecurityRuleSet.Level2 value being passed to that. However, it is important to remember that level 2 transparency is used by default, so if the attribute is not declared, then we should assume it to be used level 2. It is against “guidelines”, however, not to declare this attribute.

If the assembly is operating under the level 1 transparency model, the SecurityRulesAttribute is declared with a SecurityRuleSet.Level1 value passed to it instead.

Let’s then see what we come up with from looking at some of the core .NET Framework assemblies. In order to do this, I wrote a program which enumerated over every single assembly installed to the standard .NET Framework 4.0 installation directory, checking the SecurityRulesAttribute attribute present on each one.

The results are interesting:

  • Total Level 2
    77 assemblies
  • Total Level 2 with Obsolete Security Actions
    (this means the assembly included a SecurityPermissionAttribute with a SecurityAction value deemed obsolete under the new model)
    45 assemblies
  • Total Level 2 Lacking Assembly-wide Notation
    (this means that no  SecurityTransparentAttribute, SecurityCriticalAttribute, or AllowPartiallyTrustedCallersAttribute was found on the assembly metadata)
    53 assemblies
  • Total Level 1 
    55 assemblies

The majority of Level 2 assemblies were completely lacking notation (i.e. no SecurityRulesAttribute), which goes against Microsoft’s own guidelines. As we can see, however, there are a number of level 2′s, however the majority of the level 2′s are insignificant (except for mscorlib.dll and System.Security.dll), whereas the important .NET assemblies are what constitute the Level 1 group.

Here’s the list of Level 1 assemblies:

  • System.AddIn
  • System.Configuration
  • System.Core
  • System.Data.DataSetExtensions
  • System.Data
  • System.Data.Entity.Design
  • System.Data.Entity
  • System.Data.Linq
  • System.Data.OracleClient
  • System.Data.Services.Client
  • System.Data.Services
  • System.Data.SqlXml
  • System.Deployment
  • System.DirectoryServices.AccountManagement
  • System.DirectoryServices
  • System.DirectoryServices.Protocols
  • System
  • System.Drawing
  • System.EnterpriseServices
  • System.IdentityModel
  • System.Net
  • System.Runtime.Serialization
  • System.ServiceModel.Activation
  • System.ServiceModel
  • System.ServiceModel.Web
  • System.Transactions
  • System.Web.ApplicationServices
  • System.Web
  • System.Web.Entity
  • System.Web.Mobile
  • System.Web.Services
  • System.Windows.Forms.DataVisualization
  • System.Windows.Forms
  • System.WorkflowServices
  • System.Xml
  • System.Xml.Linq
  • PresentationCore
  • PresentationFramework.Aero
  • PresentationFramework.Classic
  • PresentationFramework
  • PresentationFramework.Luna
  • PresentationFramework.Royale
  • PresentationUI
  • System.Printing
  • System.Windows.Presentation
  • UIAutomationProvider
  • UIAutomationTypes
  • WindowsBase

These are some of the most important assemblies in the BCL, and they’re all using the legacy security model.

But you know, all of this is just an observation, it doesn’t mean anything. Indeed, I was just recounting reality right now. What I just talked about isn’t the primary reason not to use it. What caused my jaw to drop was when I found out about the issues Visual Studio’s code coverage had with it.

Visual Studio Code Coverage Doesn’t Work With It

…if you’re assembly is annotated, at least. Deal breaker for me.

By “annotated”, I mean your assembly is set to either be SecurityCritical, SecurityTransparent, or AllowPartiallyTrustedCallers

If you do any of those, and then annotate the rest of your code properly using FxCop and SecAnnotate, you will get the following error if you run any unit tests with Visual Studio’s built-in code coverage:

 System.TypeInitializationException: The type initializer for ‘xxx’ threw an exception. —>
System.MethodAccessException: Attempt by security transparent method ‘Microsoft.VisualStudio.Coverage.Init_[...].Register()’ to call native code through method ‘Microsoft.VisualStudio.Coverage.Init_[...].VSCoverRegisterAssembly(UInt32[], System.String)’ failed.
Methods must be security critical or security safe-critical to call native code.

The reason why this happens is because during instrumentation a bunch of unattributed methods get inserted that make P/Invoke calls. I find it a little ridiculous that Microsoft’s own tools don’t support this new model, and especially one that I feel is rather critical to the development process. Microsoft clearly does not use its own tools for code coverage analysis, at least with the assemblies that are level 2.

So, my advice if you are starting a new library or whatnot: If security is a priority with you (like if you want to allow partially trusted callers), then use the legacy model. If it isn’t, then you can declare level 2 compatibility in your assembly metadata, but don’t add any other level-2 specific assembly-wide attribute until the model is more supported.

 

[ExcludeFromCodeCoverage] — Oh, the Pain!

If you make use of Visual Studio’s built-in code coverage feature, you are probably aware of the existence of the ExcludeFromCodeCoverage attribute. This attribute, when decorating a piece of code, will exclude that code from all code coverage instrumentation. The end effect of its use is the total exclusion of the method or type from the code coverage report we all are treated with at the conclusion of the testing session.

While it does its job, its use is a bit intrusive, especially since all we are doing is appeasing a specific testing tool. It would be nice if there was some sort of coverage configuration file one could edit in order to exclude specific code elements, but no such thing exists in Visual Studio’s code coverage system. Perhaps the visibility of such things is a benefit, because it makes the fact that the code isn’t being counted in the coverage metric blatantly obvious. But it’s only obvious if you are actually looking at that code and not just a coverage report along with some top-level project files. Plus, the assumption is, is that you are a competent individual who wouldn’t be itching to exclude something from coverage analysis unless you had a good reason to do so.

With all that said, it’s my opinion the process of realizing code coverage exclusion through the use of the ExcludeFromCodeCoverage attribute is clumsy and not ideal. This gets further exacerbated when we want to go beyond the type-level and exclude an entire namespace from code coverage. That isn’t an option with the ExcludeFromCodeCoverage attribute; you are limited to types, methods, properties, indexers, and events.

Well there is a better way. Using PostSharp, we can devise our own scheme of coverage exclusion by creating a very simple aspect that will allow us to target entire namespaces if we wish, as well as smaller items in scope, all without having to touch any of the code being excluded.

The DisableCoverage Aspect

The aspect we’ll be designing here will act as a vehicle for the efficient delivery of our adored ExcludeFromCodeCoverage attribute to the intended pieces of code we wish to exclude. We will then make use of PostSharp’s multicasting feature in order to steer this vehicle.

The code for the aspect can be found, and, as you can see, it’s extremely simple:

[Serializable]
[AttributeUsage(AttributeTargets.Assembly)]
[MulticastAttributeUsage(MulticastTargets.Class | MulticastTargets.Struct)]
[ProvideAspectRole(StandardRoles.PerformanceInstrumentation)]
public sealed class DisableCoverageAttribute : TypeLevelAspect, IAspectProvider
{
    public IEnumerable<AspectInstance> ProvideAspects(object targetElement)
    {
        Type disabledType = (Type) targetElement;

        CustomAttributeIntroductionAspect introducedExclusion
            = new CustomAttributeIntroductionAspect(
                new ObjectConstruction(typeof (ExcludeFromCodeCoverageAttribute)));

        return new[] {new AspectInstance(disabledType, introducedExclusion)};
    }
}

All this aspect does is introduce the ExcludeFromCodeCoverage attribute into all applied targets. I have the AttributeUsage of this attribute set to target only assemblies because using this aspect in any other way defeats its entire purpose. The MulticastAttributeUsage of this attribute, on the other hand, is targeting classes and structs. The reason I do this is so that the ExcludeFromCodeCoverage attributes we’re introducing are done so at the type-level, which is the most granular level of scope I wish to specify when using this aspect.

Let’s say you have a namespace named Bad.Tomato containing a bunch of classes you wish to exclude from coverage. To use our aspect in order to realize this wish, you would open up your project’s AssemblyInfo.cs file and add the following assembly-level attribute declaration:

[assembly: DisableCoverage(AttributeTargetTypes="Bad.Tomato.*")]

This will then result in the exclusion of all code elements belonging to the Bad.Tomato namespace from coverage analysis.

Maybe targeting a whole namespace is a bit too drastic for your tastes…maybe we only want to exclude a single class named Bad.Tomato.Farmer. Ok…then:

[assembly: DisableCoverage(AttributeTargetTypes="Bad.Tomato.Farmer")]

Hooray, no more ExcludeFromCodeCoverage! If you want to get even more granular, you can, and I believe you can make use of regular expressions here as well.

 

Note: The following article is more an exploratory piece than anything; using any of the code or the approaches discussed in a production setting is not recommended. This article is meant to be as part of a build-up for an ultimate conclusion on the matter.

The Problem

In my previous article on the topic, I got into how we can extend PostSharp’s weaving capabilities in order to add support for special parameter validation aspects.

If you happened to examine any assemblies built using this technology with a static analysis tool like NDepend, you might have had alarms going off complaining about an excessive amount of boxing occurring. This is never a good thing, so let’s dissect this a bit.

The sole concrete validation attribute provided in the example was the NotNullAttribute. The base definition of the validation method employed by this attribute and all other validation attributes looked like the following:

        public abstract void Validate(object target, object value, string parameterName);

So, as we can see, all parameter types must be upcasted to the object type prior to being passed to the above method. Consequently, this also implies that all value type parameter values be boxed prior to being passed to Validate as well.

However, our sole concrete validation attribute (NotNullAttribute) is something we would never decorate a parameter known to be a value type anyway, since value types cannot be null! To do so would be silly, and (if you implemented the compile-time validation routine correctly), would result in a compile-time error.

But even if it is true that no value type parameters are decorated with a validation attribute, you may still have excessive boxing occurring in your assembly. This is because in the example provided in the previous article, box instructions are issued for both value type and generic type parameters.

So, if you’re like me, in that a large number of your methods use generic type parameters and you happen to be validating those parameters, you will have excessive instances of the box instruction in your code. So why does our previous example box generic type parameters? Simply because it takes the lazy way out: those generic type parameters may be bound to value types, they may not, so we box just in case they are.

What happens when you box a generic type parameter that is bound to a value type? Well, it boxes it like normal. What happens when you box a generic type parameter that is bound to a reference type? Nothing, it is essentially a nop. So, in actuality, because boxing will only actually be occurring when we’re binding the generic type parameters to value types, this may not seem like a very big deal to you anymore.

However, we can do better, and avoid boxing altogether for the most part. Among other things, the boxing metric from the analysis tool is rendered useless if we don’t clean up the number of box instructions in the IL. I’m going to go over how to go about doing just this; be aware, though, that my solution is not 100% complete, and I’m still trying to figure out how to support a few “corner” (yeah…not exactly) cases.

The Solution

Let’s take a look at how we can solve this problem.

A Generic Validation Method

One of the simplest ways to address this problem is to have a validation method that will accept a generic type parameter. So…something like the following:

public void GenericValidate<T>(object target, T value, string parameterName)
{...}

We then need to modify our actual weaving code so that it calls this method. Calling generic methods using IL is much more involved than it is when using C#, as the C# compiler handles all the required nasty business for us. All of my weaving code is in a class named ValidationInstructionWriter. One of its responsibilities is emitting calls to the parameter’s validation method, and it is this code that we need to change.

Before we go into those changes, however, let’s go over the general strategy at play here. Or, to put it another way, let’s look at the strategy that arises from some limitations encountered when trying to correct this problem.

Limitations and Things to Do

First of all, I’m not entirely replacing my original validation method with this new generic one. Only when we have a generic type parameter will we be calling the generic validation method. If, instead, we have a non-generic value or reference type, we will actually be calling the original method. Obviously, in the latter case, no box instruction is emitted when the parameter is known to be a reference type, however one is emitted if it is known to be a value type obviously.

Why? Well, the reason is very simple: I don’t know how to call generic methods using the PostSharp SDK unless I already have a generic type parameter. Indeed, this is the very reason as to why I originally only had a the validation method accept object types in the previous article on this topic. I certainly have attempted to figure out how to do this, however I have been unsuccessful so far. It certainly isn’t trivial, and isn’t expected to be, even though it would seem to be fairly standard thing at first (welcome to MSIL, by the way). If anyone out there does know how to do this, I’d love to know.

The PostSharp SDK is an unsupported tool, so I refrain from bothering the PostSharp developers with questions related to it. I’m also going to refrain sharing the problems I encounter when doing this here as well, although I will if there’s some interest. Regardless, I will continue to attempt to figure out how to do it, and I will be sure to let the world know once I figure it out.

In order to insert some balance into this approach, our validation attributes are designed so that the validation method that actually gets overridden in all concrete validation attribute types is the original validation method and not the new generic method. Having to override two different methods would be a bit ridiculous, and would kill this whole thing for me. The generic validation method, thus, is not virtual or abstract; all it does is simply do a direct call to the original validation method.

What’s the point of all of this then? Well, it gets rid of all those extraneous box instructions that would have been littering our code, and it also defers the details of the generic type parameter conversion to the C# compiler. It is also one step closer to the totally correct solution, and it gets the discussion on this topic rolling. Besides, if you remember, if a generic type parameter is bound to a reference type, a box instruction causes no performance hit. However, if it is bound to a value type, then we will get the penalty that comes with boxing. Indeed, that very case is the only one that is negatively impacted by this decision.

Frankly, it’s hardly a setback to have to work with object types instead of unconstrained generic types anyways, which offer no additional capabilities over object typed values. Taking it all into account, this compromise is acceptable under the standards I have for my projects. Frankly, even the original solution is, given of the immense benefits I’ve been discovering from being able to validate parameters in this fashion. Regardless, I’m not completely pleased with the final solution.

Let’s go over some constructs you’re going to see in the code. I’m not going to completely go over everything, as some things were described in the previous article, and other things you’ll need to figure out for yourself.

EntityDescription

I have a custom type I use named EntityDescription. This object basically consists of the  ParameterDeclaration‘s ParameterType, system Type, and name. Assuming you have a field set to the ParameterDeclaration of the parameter we’re validating, it is initialized like so:

EntityDescription description = new EntityDescription(
  _parameter.ParameterType,
  _parameter.ParameterType.GetSystemType(_genericTypeArguments, _genericMethodArguments),
  _parameter.Name);

This is basically just used as a container for commonly needed entity information, and is used outside of the specific scenario we’re covering today.

ValidationCallParameters

Another custom type I use if the ValidationCallParameters type. This is a type specifically purposed for containing the data required for emitting a call to one of our validation methods. I use this type for emitting both parameter and method validation calls, however this article (and the previous article) only concerns parameter validation. Assuming the index of the parameter you are validating is stored in a variable named targetIndex, you would initialize an instance of this type like so:

ValidationCallParameters parameters = new ValidationCallParameters(
    OpCodeNumber.Ldarg,
    targetIndex,
    description.EntityType.IsGenericParameter
        ? Validator.GenericValidationMethod
        : Validator.ValidationMethod);

Note that, for the validation method, I tell it use the GenericValidationMethod only if the parameter type is generic.

Let’s go over the actual code that emits a call to our new validation method.

EmitValidationCall

/// <summary>
/// Emits a call to a method responsible for validating a described entity, using the provided parameters
/// to arm it.
/// </summary>
/// <param name="parameters">The set of data required in order to weave this validation call.</param>
/// <param name="description">A full description of the entity being validated.</param>
public void EmitValidationCall(ValidationCallParameters parameters, EntityDescription description)
{
    // This adds a new instruction sequence to the current block.
    CreateInstructionSequence(NodePosition.Before);

    IMethod validationMethod = FindValidationMethod(parameters, description);

    Writer.EmitInstructionField(OpCodeNumber.Ldsfld, _validatorField);
    Writer.EmitInstruction(!Context.Method.DeclaringType.IsNullable()
                                ? OpCodeNumber.Ldnull
                                : Context.Method.GetFirstParameterCode());

    Writer.EmitInstructionInt16(parameters.TargetOpCode, (short)parameters.TargetIndex);

    if (description.EntityType.IsValueType)
        Writer.EmitInstructionType(OpCodeNumber.Box, description.EntityTypeSignature);

    Writer.EmitInstructionString(OpCodeNumber.Ldstr, description.EntityName);
    Writer.EmitInstructionMethod(parameters.ValidationMethod.GetFirstParameterCode(),
                                    validationMethod);

    Writer.DetachInstructionSequence();
}

The CreateInstructionSequence is a simple routine that behaves in the manner described by the comments above its call. The GetFirstParameterCode extension method is described in my previous article.

As we can see here, we do emit an explicit box instruction if the type of a known value type. If it is not a known value type, however, we won’t box. There really isn’t much new in here from the previous article, except for the call being made to FindValidationMethod, which is a new method introduced to solve this problem. Let’s take a look at that method.

FindValidationMethod

/// <summary>
/// Locates the <see cref="IMethod"/> instance for our validation method.
/// </summary>
/// <param name="parameters">The set of data required for the validation call.</param>
/// <param name="description">Optional. The description of the entity we're validating.</param>
/// <returns>The <see cref="IMethod"/> instance for our validation method.</returns>
private IMethod FindValidationMethod(ValidationCallParameters parameters, EntityDescription description=null)
{
  if (null == description)
      return Context.Method.Module.FindMethod(parameters.ValidationMethod, BindingOptions.Default);

  if (description.EntityType.IsGenericParameter)
  {
      MethodInfo validationInfo = (MethodInfo) parameters.ValidationMethod;

      MethodInfo genericValidationInfo =
          validationInfo.GetGenericMethodDefinition().MakeGenericMethod(description.EntityType);

      return
        Context.Method.Module.FindMethod(
           genericValidationInfo, BindingOptions.RequireGenericInstance & BindingOptions.RequireGenericMask);
  }

  return Context.Method.Module.FindMethod(parameters.ValidationMethod, BindingOptions.Default);
}

This method has an optional parameter for purposes outside of what we’re covering.

So, as we can see here, if we have a generic parameter, we need to call our method in a special way. You may want to add a check in there that ensures ValidationMethod is a generic method before attempting to get a generic method definition from it (which will throw an exception if it isn’t). This is taken care of in our original initialization of the ValidationCallParameters object.

There you go, this is a step on the path to making our validation solution use generics.

(Aphex Twin’s Analord series is some great stuff, by the way).

 

Immutable Properties

Microsoft likes to say that an auto-implemented property declared with a private set accessor is immutable. This is not entirely true, in a number of ways. One can always use reflection to assign values to a property, regardless of whether the set accessor is private or public. But putting conspiracy theory cases like that to the side, these properties still cannot be considered immutable due to the fact that, although the outside world cannot set their values, they are settable from anywhere inside the class.

The only type of property I would consider immutable is one that returns a read-only field and lacks a set accessor entirely. Of course, the very field that gets returned, provided it is not a value type, may very well not be immutable itself, but I digress.

I found an interesting way to assign a value to a property declared with a private set accessor that doesn’t use reflection. It does, however require some participation from the class itself. I’m not recommending actually using the approach I’m going to go over in any real-world code, as most of the time a read-only property is read-only for a good reason. Having to skirt around accessibility levels should never be the only way to proceed with an implementation, and if it is, then there is a problem with your design or approach as a whole. But, if you know what you’re doing, this may be of interest to you.

But putting all that sensible stuff aside, I’ve found an interesting one can go about setting the value of a property with a private set accessor using Expressions. More specifically, we can take an expression of a property’s get accessor being accessed and turn it into one where a value is being assigned to the property’s set accessor. This could be useful for instances where you need to initialize some sort of domain object that features limited accessibility in regards to setting the values of its properties.

An Example: PropertyMap

I developed a PropertyMap type which allows you to define values for a type of object’s properties outside of and independent of any instance of that type. The PropertyMap is populated with values that should be set to different properties of the target type. The properties are specified through the use of an ExpressionReader class that features a ReadName method that returns the name of a member being accessed. There are plenty of examples online as to how to use Expressions in order to get the names of code elements, so I’ll defer you to those examples if you wish to learn more about this.

As a side note, before we get to the code, just note I had to condense the names of the type parameters in order for the code to fit on the page the best. Typically, they’re a bit more descriptive.

Here’s the code for the Add method:

/// <summary>
/// Adds a mapping entry for the property being expressed.
/// </summary>
/// <typeparam name="TValue">The type of value returned by the property.</typeparam>
/// <param name="propertyExpression">An expression accessing a property's getter method.</param>
/// <param name="value">
/// The value to be assigned to the property during a future mapping operation.
/// </param>
public void Add<TValue>([NotNull]Expression<Func<T,TValue>> propertyExpression, TValue value)
{
    string propertyName = ExpressionReader.ReadName(propertyExpression);

    if (!ContainsKey(propertyName))
        Add(propertyName, value);
}

Alright, nothing too crazy here.

You can then pass the PropertyMap to an instance of the targeted type, which the instance can then use to assign values to its properties via successive calls to a Map function, each time providing an expression that accesses a different property.

/// <summary>
/// Maps a preconfigured value to the property being expressed.
/// </summary>
/// <typeparam name="TValue">The type of value returned by the property.</typeparam>
/// <param name="propertyExpression">
/// An expression accessing the getter method of the property to map to.
/// </param>
public void Map<TValue>([NotNull]Expression<Func<TValue>> propertyExpression)
{
    string propertyName = ExpressionReader.ReadName(propertyExpression);

    // Validation occurs here...Excluding this from the post.

    MemberExpression propertyGetterExpression
        = (MemberExpression) propertyExpression.Body;
    ConstantExpression instanceExpression
        = (ConstantExpression) propertyGetterExpression.Expression;

    T instance = (T) instanceExpression.Value;
    Action<T, TValue> propertySetter = CompileSetter<TValue>(propertyGetterExpression);

    propertySetter(instance, (TValue) this[propertyName]);
}

The above extracts the property getter expression and then calls CompileSetter to create an Action that invokes the set accessor of the type.

/// <summary>
/// Compiles a property setter method derived from the provided property getter expression.
/// </summary>
/// <typeparam name="TValue">The type of value returned by the property.</typeparam>
/// <param name="propertyGetterExpression">
/// An expression accessing a property's getter method.
/// </param>
/// <returns>
/// A compiled <see cref="Action{T,TValue}"/> which will set the value of the property
/// accessed by
/// <c>propertyGetterExpression</c> to what's provided.
/// </returns>
private static Action<T, TValue> CompileSetter<TValue>(Expression propertyGetterExpression)
{
    ParameterExpression valueParameterExpression
        = Expression.Parameter(typeof (TValue), "value");
    ParameterExpression instanceParameterExpression
        = Expression.Parameter(typeof (T), "x");

    BinaryExpression assignValueExpression
        = Expression.Assign(propertyGetterExpression, valueParameter);

    Expression<Action<T, TValue>> propertySetterExpression
        = Expression.Lambda<Action<T, TValue>>(assignValueExpression,
                                               instanceParameterExpression,
                                               valueParameterExpression);
    return propertySetterExpression.Compile();
}

Let’s go over a very rough example of this in action. Here’s the participating class:

public class Example
{
    public string Label
    { get; private set; }

    public void Map(PropertyMap<Example> map)
    {
        map.Map(() => Label);
    }
}

And here’s an example of invoking that class:

PropertyMap<Example> map = new PropertyMap<Example>
                {
                    { x => x.Label, "This works!" }
                };

Example example = new Example();

example.Map(map);

// The string variable below will be set to "This works!"
string label = example.Label;

I was initially somewhat surprised that this worked, we are basically changing the x => x.Label expression into a (x,value) => x.Label = value expression. Obviously this all fails if there is no set accessor at all.

The reasons why this works is something I’ll cover in another post in the future.

Should I Use This in My Code?

If you are unsure and have to ask me, then no, you shouldn’t use this in your code. For most cases where you could use this, you would be at best clever, and at worst irresponsible; however, for some situations, this could be considered an appropriate approach. Going into what those specific situations might be is far and beyond outside the scope of this article.

 

If there is one piece of an Exchange or Outlook appointment that is as important as it tends to be misunderstood, it would certainly have to be the Organizer property.

This lovely little fellow returns a string which represents the name of the individual who owns the appointment, or, as Microsoft puts it in the Outlook Object Model (OOM) documentation, it is “…the name of the organizer of the appointment.” As helpful as that is, what does it even mean for one to be an organizer of an appointment? I’m going to cover these questions as well as go over why it is very dangerous to rely on this property in your product’s code.

What is an Organizer?

Exchange server protocol documentation defines the organizer as “the owner or creator of a conference or event.”

I hate to contradict official Exchange white papers, but although the organizer is indeed the owner of an event, they are not necessarily always the “creator”. A delegate for a manager can create an appointment on that manager’s calendar, however the delegate will not be marked as the organizer; rather, the manager will be the organizer. You may say, “Well, the delegate carries out actions in the manager’s name.” which is not entirely correct, because a normal delegate actually very much retains their own identity, and this is reflected by some various properties which will reflect the delegate’s name on the appointment.

Let’s do a better job in defining what an organizer is: The organizer of an appointment can be described as the owner of the calendar in which an appointment is first created. By saying “owner of the calendar”, I’m referring to the individual for which the mailbox store containing the calendar belongs to. The organizer is commonly referred to (by Microsoft and others) as the meeting organizer, however it is important to remember that not all appointments are meetings, but all appointments have an organizer. This fact is important in the very definition of what a meeting is, which is an appointment that is extended “…to contain attendees in addition to the organizer.” [MS-OXOCAL - 1.3.1.2]

So what’s the importance of being an organizer? What special privileges or capabilities does one acquire when donning the Organizer cap? What are some important limitations?

  • The fact that an individual is an organizer is displayed to attendees in the meeting request; this alone is probably one of the most important consequences of being the organizer, at least as far as day-to-day business dealings are concerned.
  • The organizer is the individual that will receive all responses to any meeting requests sent by or through the organizer; that is, unless it has been configured for all responses to go to a delegate instead.
  • Once an appointment object has been saved, you cannot change who the organizer is (or so they say). This little factoid is probably one of the first bits of information developers or users may encounter when inquiring about the nature of the appointment’s organizer. In fact, I’ll bet that’s the reason you’re reading this very article.
  • Other than some special do’s and don’ts that one must follow when working with appointments in the very low levels of things, there’s really not much else.

While there are certainly other actions an organizer can take that a normal attendee typically cannot (such as adding an attendee, removing an attendee, etc.), all of these types of actions are wholly dependent on the permissions and type of access the individual has in relation to the original appointment item; they have nothing to do with being the organizer. This is why a delegate can do everything an organizer can.

Regardless of the actual limited number of automatic perks that come with being an organizer, many third-party solutions out there tend to use the fact that someone is an organizer as a simple way to see if the user owns and thus can modify/mess around with an appointment. Although nothing is easier than checking if the current user’s name matches the string returned by the Organizer property, this is a dangerous way to proceed for a number of reasons we’ll get into later.

How is the Organizer’s Identity Determined?

Folks who work with Outlook solutions generally refer to the OOM’s Organizer property of an appointment item to determine who the organizer is. As I’ve stated before, this property returns a string representing the name of the organizer. So…is that it then? Is the identity of the organizer persisted through a simple string property on the appointment object? Where does this Organizer property actually get its value?

These are all questions with, surprisingly, unclear answers. While some of the above is addressed by Microsoft on the MSDN, they do not, in particular, (from what I’ve seen) seem to mention the exact origin of the value returned by the Organizer property anywhere.

It takes only simple deduction to realize that Outlook is aware of more about the organizer than simply the name of the organizer. For instance, create a new appointment on your calendar, and then click on the Scheduling Assistant ribbon button in the Show group. You’ll see something similar to the following:

Scheduling Assistant Displaying the Organizer

Scheduling Assistant Displaying the Organizer

If you look at the icon next to my name, you’ll that I’m the organizer of the meeting (the icon being the “organizer” icon and all). So, we see that it knows the name of the organizer. Isn’t that what we get by looking at the Organizer property?

Well my friends, you’ll be pleased (horrified) to know, that the name shown in the above picture and the value returned by the Organizer property do not come from the same place. In fact, they are not linked at all, the fact that they tend to be the same value is merely a consequence of actions taken by the client. It is indeed possible for them to differ in value (even if they originally were the same value) as well, however that’s outside the scope of this article.

Back on topic, if we take a closer look at the entry above, we’ll see that Outlook is actually aware of the true identity of the user that is marked as the organizer. You can see this simple by moving your mouse over the name. This will result in something similar to the image below:

Scheduling Assistant Displaying the Organizer with Additional Information

Scheduling Assistant Displaying the Organizer + Additional Information

Simply based on the fact that we’re seeing the card pictured above should tell us that we are looking at the user’s actual address entry as well as some other information. Indeed, clicking on one of the icons in the above card will lead us to the user’s contact details.

What does this all tell us? This tells us that Outlook and Exchange are intimately aware of the identity of the organizer of the appointment; they do not rely simply on a literal name for the organizer. They are aware of enough information regarding the organizer to be able to pull the contact information for the user. What does that require? It requires the entry ID of the entry for the user in an address book (i.e. the GAL).

So where is the organizer’s information stored in the appointment, and in what form? Roughly speaking, information regarding the organizer is stored in two separate places, one of them being, in my opinion, the most official of the two as far as what makes some an actual “organizer”; however, each has its own set of consequences realized with regards to the user indicated as being the organizer. Let’s go over those two places that collectively determine who the organizer is.

I: The Recipient Table

The designation of the organizer in a meeting’s recipient PropertyRowSet is what, I believe, actually decides who the organizer is, as it has the greatest amount of influence on the functional implications of having the status of being the organizer.

A PropertyRowSet is a data structure discussed in the [MS-OXCDATA] Exchange server protocol document is simply a structure that has a counted number of PropertyRow structures. Essentially, it is a table where the number of columns in each row is not exactly set in stone (sounds like something right up Microsoft’s alley). When discussing a recipient table, these PropertyRow structures are actually RecipientRow structures, which are also introduced in the [MS-OXCDATA], but expanded upon in [MS-OXOCAL - 2.2.4.10], which begins to go over the actual properties one may encounter in an entry in the recipient table.

By the way, I love how Microsoft introduces the concept of a RecipientRow: “It is rather complex but can be considered as a sequence of three different parts…”

When we step outside of the design and into the more real-world side of things, we’ll find implementations of the recipient table on any type of message, including appointments and meetings. We can retrieve the recipient table by making an IMAPIProp::OpenProperty call, specifying PR_MESSAGE_RECIPIENTS for the property tag and IID_IMAPITable for the interface identifier. You’ll be able to do this more easily by using either OutlookSpy, MFCMapi, which all have options named something similar to “Open Recipients Table”. I’m not sure how easy it is to get to what we want her from the OOM, or even Redemption, but it should be accessible using the appropriate property tags (at least in Redemption’s case…I try to avoid the OOM when doing anything off the beaten path).

Inside the recipient table, we’ll find a RecipientRow for every single attendee to the meeting, including one for the organizer. On each row is one particular property of importance, and that is the PR_RECIPIENT_FLAGS property. You can find information regarding the specifics of this property in the [MS-OXOCAL], however I’ll help you out a bit and plop a picture relevant to what we’re talking about below:

Structure of the PR_RECIPIENT_FLAGS Property

Structure of the PR_RECIPIENT_FLAGS Property

We can see above a number of bit fields we can set. The bit we’re interested in is the second bit, which is known as the recipOrganizer bit. Setting this bit to 1 makes the user associated with the RecipientRow that this property is in the de facto organizer of the appointment. This then implies that only a single RecipientRow can have this bit set. I’m not sure what’ll happen if more than one does have it set, you’ll have to build a custom MAPI client to find out.

So, in other words: the organizer is officially determined to be the user whose has the recipOrganizer bit set in their associated RecipientRow in the appointment’s recipient table. There are other properties in the RecipientRow besides the recipient flags, including one or more that store the recipient’s entry ID. No doubt, then, it is through the user’s RecipientRow that Outlook is able to retrieve the kind of information we were being treated to earlier when hovering our mouse over our name in the Scheduling Assistant.

Unfortunately, this is not the entire story. Despite the designation via the user’s RecipientRow being the official way of becoming the organizer, it may surprise you to know that the Organizer property returned by the OOM (I can’t speak as for Redemption, didn’t test it out), which is the most common means of exposure of the organizer’s identity to the outside via an API (in the case of an Outlook solution, at least) is in no way influenced by the recipOrganizer bit, the PR_RECIPIENT_FLAGS property, or any at all to do with the recipient table!

This leads us to the second place an organizer is “set”.

II. PR_SENT_REPRESENTING_NAME

The value returned by the Organizer property does not originate from the appointment’s recipient table at all. Instead, it actually comes from the PR_SENT_REPRESENTING_NAME property, found on the appointment itself. So, there you go…that’s where the money is.

You’re probably already aware (from being told so somewhere else) that you cannot change the organizer. Consequentially, the Organizer property is read-only. You cannot set the Organizer property. Well, while it is more or less true that you cannot change who the real organizer is, you can have influence on what Organizer returns.

It may surprise you to know that by changing the value of PR_SENT_REPRESENTING_NAME, you will change what the Organizer property returns. Some places in Outlook do use this property to display the organizer’s name, so you will influence those areas. In some places, however, Outlook defers to the display name stored in the recipient table. It does not seem possible to edit a RecipientRow once a message has been saved; at least, I am unable to do so using OutlookSpy and MFCMapi. Perhaps it is still technically possible to with the Redemption library or raw Extended MAPI. I’d be interested to know if anyone has any insight on that.

Here’s some code to demonstrate how to change the Organizer property in Outlook (when we’re in Outlook, we have to get the correct DASL property name):

private void ChangeOrganizer(AppointmentItem appointment)
{
  PropertyAccessor accessor = appointment.PropertyAccessor;

  accessor.SetProperty("http://schemas.microsoft.com/mapi/proptag/0x0042001F", "Matt Weber");

  // 'appointment.Organizer' will now return "Matt Weber".
}

And here’s some code to do the same with Redemption, which is a little bit simpler:

private void ChangeOrganizer(RDOAppointmentItem appointment)
{
  appointment.SentOnBehalfOfName = "Matt Weber";
}

An interesting thing to note is that the PR_SENT_REPRESENTING_NAME property can be found on both appointment and normal mail messages, and thus can be set on either. Regardless, only appointment objects will have an actual “organizer”. Changing the PR_SENT_REPRESENTING_NAME property on an email will change the name of the sender of the email.

Why Relying on the Organizer Property is Dangerous

Seeing how the Organizer (and thus the PR_SENT_REPRESENTING_NAME property) is not actually (guaranteed to be) based on who the real organizer is, relying on it in your program code can be very dangerous. It is really a bad idea, and I’ll provide a very real-world example showing why.

If you cater to customers that belong to the corporate world, you should be aware of and always plan on the possibility of a merger or acquisition involving that customer occurring. Many times, during the process of the merger of acquisition, company-wide changes to the display names of their users will be rolled out via Active Directory. Perhaps the company is now becoming a more “world-wide” company, and thus needs to append the name of a country to all employees’ display names based on the location of their office.

When changes are made to User objects in Active Directory, those changes are going to eventually propagate to Exchange’s Global Address List via a management agent. This means, then, that those changes will be reflected in all address entry objects returned when operating within an Outlook or Exchange environment. Guess what happens to the values returned by properties like PR_SENT_REPRESENTING_NAME and, ultimately, the OOM’s Organizer property? Nothing! They will remain the same; they are not synchronized or hooked up to Active Directory in any way shape or form.

So what will happen then, if you happen to have code responsible for determining if the current user is the organizer of an appointment, which happens to use current Active Directory information for figuring out who the current user is, and the appointment’s Organizer property for figuring out who the organizer is? It won’t work anymore, because they will be completely out of sync.

Therefore, it is very dangerous to rely on, frankly, any string property relating to users exposed by MAPI’s data model.

What’s the alternative here?

The proper way to establish organizer identity is to look past the OOM’s Organizer property and PR_SENT_REPRESENTING_NAME property, and instead use the PR_SENT_REPRESENTING_ENTRYID property (which is exposed by Redemption with the SentOnBehalfOfEntryId property) to retrieve the address entry of the user. This method will survive abrupt, organization-wide changes committed to Active Directory.

The best alternative, however, would be to defer to the recipient table. You would need to go over each RecipientRow until you located the one with the recipOrganizer bit set, and then use the PR_ENTRYID property located in that RecipientRow in order to open up the user’s associated address entry. Note that there is also a PR_RECIPIENT_ENTRYID which may be available and I am not sure as to what the different might be between the two properties; in all instances I’ve observed, both the PR_ENTRYID and PR_RECIPIENT_ENTRYID properties had the same value.

 

I finally got around to setting up and migrating all of my previously written articles to a new permanent website to replace the old one that died with the old server. I had been using a temporary solution for some time now, and although it did its job well, it has outlived its usefulness.

With the new website comes a new domain name (http://badecho.com), although I’ll be keeping my old domain (http://omniscientist.net) active until I’ve had 301 redirects in place for all the articles for a few months or so.

Lots to do though still..need to set up management accounts with Google, etc.

 

I love expression trees. They were a great addition to the .NET Framework. I do get a sense from the community that they are somewhat underutilized, however that may just be the nature of things that lack triviality. Let’s spend some time on expression trees and talk a bit about how one might go about comparing one expression tree to another.

Expressions and Reference Equality

If you’ve ever spent some time pouring over the MSDN documentation for the Expression class, you may have noticed that it does not override Object.Equals. This means, then, that only reference equality will be checked when comparing two Expression objects. It will not check equality in the sense that the expression trees deriving from the Expression objects look and function the same.

Take a look at an example of this below:

    Expression<Func<string, bool>> first = x => x.Length == 4;
    Expression<Func<string, bool>> second = x => x.Length == 4;

    Console.WriteLine(first.Equals(second)); // Output is "False"

There is nothing wrong with this; this is all expected when you forego overriding Object.Equals. But what if we want to be able to tell whether or not two separately provided expression trees are, in essence, “the same” in the sense that saying x.Length == 4 is the same as saying x.Length == 4?

An example where this would be nice is if we were maintaining a dictionary of ImportantStuff that used Expression objects representing conditions as keys. Let’s call this an ExpressiveDictionary. An example of its use is below:

    // ExpressiveDictionary implements IDictionary<Expression<Func<TKey,bool>>, TValue>
    ExpressiveDictionary<HumorlessKey> dictionary = new ExpressiveDictionary<HumorlessKey>();

    ImportantStuff stuff = new ImportantStuff();

    dictionary.Add(x => x.EasilyOffended, stuff);

    Console.WriteLine(stuff.Equals(dictionary[x => x.EasilyOffended])); // Output is "True"

I’m not saying that something like the above example is something you want to have in your product necessarily, rather it is there for demonstrative purposes. Personally, I decided to figure out a solution for this as the new platform I’m developing had presented a problem which merited its use.

I’m going to present a portion of that solution in this article; the remaining portions will be covered in a future article.

A Custom Equality Comparer : ExpressionEqualityComparer

We’re going to need to go full throttle with this one. We’re going to need to essentially override the standard Equals logic, and we want our logic to be able to be used in a Dictionary-like class. This means, then, that we’re going to need to implement our own custom IEqualityComparer<T>. Starting there will tell us quickly what exactly we need to do.

During one of my forays into the bowels of the Internet, I stumbled upon a solution to this problem that is part of a larger project known asLINQ to db40. Other than its name, there isn’t much else I know about this project. The source code for this project may be found here. The solution to this particular problem offered by this project was helpful in getting me started, however it was designed to work against the first incarnation of the Expression type, which came out with .NET Framework 3.5. Attempting to use this solution with .NET Framework 4.0 wouldn’t end up working out too well for you.

The Expression type has undergone many changes with .NET 4.0, and a lot of new expression types have been added. The solution I’m going to present is one that will work with .NET 4.0, with many other changes as well (not just ones for Framework version compatibility purposes).

So, let’s take a look at this equality comparer:

ExpressionEqualityComparer.cs

    /// <summary>
    /// Provides methods to compare <see cref="Expression"/> objects for equality.
    /// </summary>
    public class ExpressionEqualityComparer : IEqualityComparer<Expression>
    {
        private static readonly ExpressionEqualityComparer _Instance
            = new ExpressionEqualityComparer();

        /// <summary>
        /// Gets the default <see cref="ExpressionEqualityComparer"/> instance.
        /// </summary>
        public static ExpressionEqualityComparer Instance
        {
            get { return _Instance; }
        }

        /// <inheritdoc/>
        public bool Equals(Expression x, Expression y)
        {
            return new ExpressionComparison(x, y).AreEqual;
        }

        /// <inheritdoc/>
        public int GetHashCode(Expression obj)
        {
            return new ExpressionHashCodeCalculator(obj).Output;
        }
    }

I rarely use singletons, but felt that one was justified here as we have precedent with the Microsoft-provided EqualityComparer<T> class, which offers a default instance with its Default property.

Not much going on here, but we can plainly see what we need to implement in order to realize this solution. We’re going to need to create a class which will handle the actual comparison between two Expression objects, and then we also need to create a class which will guarantee unique hash codes for different (looking) expression trees.

Given that we are dealing with expression trees here, it should make sense that both of these classes are going to be expression visitors, or rather: subclasses of the (now) Microsoft-provided ExpressionVisitor class (new to .NET 4.0; it was internal previously).

This article is concerned with implementing the first required type shown above, namely the ExpressionComparison object. A second article may come in the future that deals with how we implement the hash code calculator.

Custom Expression Tree Comparison: ExpressionComparison

The first class we’re going to implement is an ExpressionVisitor that determines whether two expression trees are equal (in content, not only by reference). It does this by walking down both trees simultaneously, comparing each node along the way.

A note about the code before we proceed. All the code I’m providing tonight has received 100% coverage in testing from myself (let me tell you…took a lot of testing code to hit all the areas, but it sure got me acquainted with all the various flavors of expression types out there), however that does not mean the code is necessarily 100% tested, of course. I’m fairly certain that it does the job reliably, however I make no guarantees. If you have any questions about a specific part of the code, let me know.

ExpressionComparison.cs
Update: Thanks to Denis in the comments for pointing out that there was a lack of support for constant collections; code has now been updated to support constant collections.

    /// <summary>
    /// Provides a visitor that determines whether two expression trees are equal (by content, not
    /// only by reference) by walking down both trees simultaneously and comparing each node.
    /// </summary>
    public sealed class ExpressionComparison : ExpressionVisitor
    {
        private Expression _comparand;
        private readonly Queue<Expression> _comparands;

        /// <summary>
        /// Initializes a new instance of the <see cref="ExpressionComparison"/> class.
        /// </summary>
        /// <param name="firstExpression">The first expression tree to compare.</param>
        /// <param name="secondExpression">The second expression tree to compare.</param>
        public ExpressionComparison(Expression firstExpression, Expression secondExpression)
        {
            ExpressionsAreEqual = true;
            _comparands = new Queue<Expression>(new ExpressionCollection(secondExpression));

            Visit(firstExpression);

            if (0 < _comparands.Count)
                ExpressionsAreEqual = false;
        }

        /// <summary>
        /// Gets a value indicating if the two provided expression trees were found to be equal in
        /// content.
        /// </summary>
        public bool ExpressionsAreEqual
        { get; private set; }

        /// <summary>
        /// Processes the provided <see cref="Expression"/> object by loading the next node coming
        /// from the expression tree being compared against and then dispatching both to more
        /// specialized visitors for more specific comparison.
        /// </summary>
        /// <param name="node">The expression to process and dispatch.</param>
        /// <returns>
        /// The modified expression, assuming the expression was modified; otherwise, returns the
        /// original expression.
        /// </returns>
        public override Expression Visit(Expression node)
        {
            if (null == node || !ExpressionsAreEqual)
                return node;

            if (0 == _comparands.Count)
                return Fail(node);

            _comparand = _comparands.Peek();

            if (_comparand.NodeType != node.NodeType || _comparand.Type != node.Type)
                return Fail(node);

            _comparands.Dequeue();

            return base.Visit(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitBinary(BinaryExpression node)
        {
            BinaryExpression comparand = (BinaryExpression) _comparand;

            if (!AreEqual(node, comparand, x => x.Method))
                return Fail(node);

            return AreEqual(node, comparand, x => x.IsLifted, x => x.IsLiftedToNull)
                       ? base.VisitBinary(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitConstant(ConstantExpression node)
        {
            ConstantExpression comparand = (ConstantExpression)_comparand;
            IEnumerable nodeSequence = node.Value as IEnumerable;
            IEnumerable comparandSequence = comparand.Value as IEnumerable;

            // The SequenceEqual method seen here is a custom extension method. I'll post it sometime.
            bool areEqual = null != nodeSequence && null != comparandSequence
                                ? nodeSequence.SequenceEqual(comparandSequence)
                                : AreEqual(node, comparand, x => x.Value);

            return areEqual ? base.VisitConstant(node) : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitDebugInfo(DebugInfoExpression node)
        {
            DebugInfoExpression comparand = (DebugInfoExpression) _comparand;

            if (!AreEqual(node, comparand, x => x.IsClear))
                return Fail(node);

            return AreEqual(node,
                            comparand,
                            x => x.EndColumn,
                            x => x.EndLine,
                            x => x.StartLine,
                            x => x.StartColumn)
                       ? base.VisitDebugInfo(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitDynamic(DynamicExpression node)
        {
            DynamicExpression comparand = (DynamicExpression) _comparand;

            if (!AreEqual(node, comparand, x => x.DelegateType))
                return Fail(node);

            return AreEqual(node, comparand, x => x.Binder)
                       ? base.VisitDynamic(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitGoto(GotoExpression node)
        {
            GotoExpression comparand = (GotoExpression) _comparand;

            if (!AreEqual(node, comparand, x => x.Kind))
                return Fail(node);

            return AreEqual(node.Target, comparand.Target)
                       ? base.VisitGoto(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitIndex(IndexExpression node)
        {
            IndexExpression comparand = (IndexExpression) _comparand;

            return AreEqual(node, comparand, x => x.Indexer)
                ? base.VisitIndex(node)
                : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitLabel(LabelExpression node)
        {
            LabelExpression comparand = (LabelExpression) _comparand;

            return AreEqual(comparand.Target, node.Target)
                ? base.VisitLabel(node)
                : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitLambda<T>(Expression<T> node)
        {
            LambdaExpression comparand = (LambdaExpression) _comparand;

            // If lambda expression differs in return type, the expression's type property itself
            // is different. Thus, there is no need to compare return types since all expressions
            // have their types compared before anything else.
            if (!AreEqual(node, comparand, x => x.Name))
                return Fail(node);

            return AreEqual(node, comparand, x => x.TailCall)
                       ? base.VisitLambda(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitListInit(ListInitExpression node)
        {
            ListInitExpression comparand = (ListInitExpression) _comparand;

            return AreEqual(node, comparand, x => x.Initializers, AreEqual)
                ? base.VisitListInit(node)
                : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitLoop(LoopExpression node)
        {
            LoopExpression comparand = (LoopExpression) _comparand;

            if (!AreEqual(comparand.BreakLabel, node.BreakLabel))
                return Fail(node);

            return AreEqual(comparand.ContinueLabel, node.ContinueLabel)
                       ? base.VisitLoop(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitMember(MemberExpression node)
        {
            MemberExpression comparand = (MemberExpression) _comparand;

            return AreEqual(node, comparand, x => x.Member)
                       ? base.VisitMember(node)
                       : Fail(node);
        }

        ///<inheritdoc/>
        protected override Expression VisitMemberInit(MemberInitExpression node)
        {
            MemberInitExpression comparand = (MemberInitExpression) _comparand;

            return AreEqual(node, comparand, x => x.Bindings, AreEqual)
                ? base.VisitMemberInit(node)
                : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitMethodCall(MethodCallExpression node)
        {
            MethodCallExpression comparand = (MethodCallExpression)_comparand;

            return AreEqual(node, comparand, x => x.Method)
                       ? base.VisitMethodCall(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitNew(NewExpression node)
        {
            NewExpression comparand = (NewExpression)_comparand;

            if (!AreEqual(node, comparand, x => x.Constructor))
                return Fail(node);

            return AreEqual(node, comparand, x => x.Members)
                       ? base.VisitNew(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitSwitch(SwitchExpression node)
        {
            SwitchExpression comparand = (SwitchExpression) _comparand;

            return AreEqual(node, comparand, x => x.Comparison)
                ? base.VisitSwitch(node)
                : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitTry(TryExpression node)
        {
            TryExpression comparand = (TryExpression) _comparand;

            return AreEqual(node, comparand, x => x.Handlers, AreEqual)
                       ? base.VisitTry(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitTypeBinary(TypeBinaryExpression node)
        {
            TypeBinaryExpression comparand = (TypeBinaryExpression) _comparand;

            return AreEqual(node, comparand, x => x.TypeOperand)
                       ? base.VisitTypeBinary(node)
                       : Fail(node);
        }

        /// <inheritdoc/>
        protected override Expression VisitUnary(UnaryExpression node)
        {
            UnaryExpression comparand = (UnaryExpression)_comparand;

            if (!AreEqual(node, comparand, x => x.Method))
                return Fail(node);

            return AreEqual(node, comparand, x => x.IsLifted, x => x.IsLiftedToNull)
                       ? base.VisitUnary(node)
                       : Fail(node);
        }

        /// <summary>
        /// Verifies that the provided <see cref="LabelTarget"/> objects are equal.
        /// </summary>
        /// <param name="first">The first <see cref="LabelTarget"/> object to compare.</param>
        /// <param name="second">The second <see cref="LabelTarget"/> object to compare.</param>
        /// <returns>True if <c>first</c> and <c>second</c> are equal; otherwise, false.</returns>
        private static bool AreEqual(LabelTarget first, LabelTarget second)
        {
            // Label targets are commonly exist individually and many times can left at null
            // without invalidating the expression.
            if (null == first || null == second)
            {
                return first == second;
            }

            return first.Name == second.Name && first.Type == second.Type;
        }

        /// <summary>
        /// Verifies that the provided <see cref="CatchBlock"/> objects are equal.
        /// </summary>
        /// <param name="first">The first <see cref="CatchBlock"/> object to compare.</param>
        /// <param name="second">The second <see cref="CatchBlock"/> object to compare.</param>
        /// <returns>True if <c>first</c> and <c>second</c> are equal; otherwise, false.</returns>
        private static bool AreEqual(CatchBlock first, CatchBlock second)
        {
            return first.Test == second.Test;
        }

        /// <summary>
        /// Verifies that the provided <see cref="ElementInit"/> objects are equal.
        /// </summary>
        /// <param name="first">The first <see cref="ElementInit"/> object to compare.</param>
        /// <param name="second">The second <see cref="ElementInit"/> object to compare.</param>
        /// <returns>True if <c>first</c> and <c>second</c> are equal; otherwise, false.</returns>
        private static bool AreEqual(ElementInit first, ElementInit second)
        {
            return first.AddMethod == second.AddMethod;
        }

        /// <summary>
        /// Verifies that the provided <see cref="MemberBinding"/> objects are equal.
        /// </summary>
        /// <param name="first">The first <see cref="MemberBinding"/> object to compare.</param>
        /// <param name="second">The second <see cref="MemberBinding"/> object to compare.</param>
        /// <returns>True if <c>first</c> and <c>second</c> are equal; otherwise, false.</returns>
        private static bool AreEqual(MemberBinding first, MemberBinding second)
        {
            if (first.BindingType != second.BindingType || first.Member != second.Member)
                return false;

            if (MemberBindingType.ListBinding != first.BindingType)
                return true;

            MemberListBinding firstList = (MemberListBinding)first;
            MemberListBinding secondList = (MemberListBinding)second;

            return AreEqual(firstList, secondList, x => x.Initializers, AreEqual);
        }

        /// <summary>
        /// Verifies property values from two items are equal.
        /// </summary>
        /// <typeparam name="T">
        /// The type of item that the properties being compared belong to.
        /// </typeparam>
        /// <typeparam name="TMember">The type of the properties being compared.</typeparam>
        /// <param name="first">The first item having one of its properties compared.</param>
        /// <param name="second">The second item having one of its properties compared.</param>
        /// <param name="reader">
        /// Method able to extract the property values being compared from the provided items.
        /// </param>
        /// <returns>True if the two item property values are equal; otherwise, false.</returns>
        private static bool AreEqual<T,TMember>(T first, T second, params Func<T,TMember>[] reader)
        {
            return reader.All(r => EqualityComparer<TMember>.Default.Equals(r(first), r(second)));
        }

        /// <summary>
        /// Verifies that specified collections coming from the two provided items are equal in
        /// content using the provided reader to retrieve the collections as well as the
        /// provided comparer to perform the comparison.
        /// </summary>
        /// <typeparam name="T">
        /// The type of the items hosting the collections being compared.
        /// </typeparam>
        /// <typeparam name="TMember">
        /// The type of items that make up the collections being compared.
        /// </typeparam>
        /// <param name="first">The first item that has a collection to compare.</param>
        /// <param name="second">The second item that has a collection to compare.</param>
        /// <param name="reader">
        /// Method able to extract the collections from the provided items.
        /// </param>
        /// <param name="comparer">
        /// The comparer to use to compare the content of the collections.
        /// </param>
        /// <returns>
        /// True if the collections are equal according to <c>comparer</c>; otherwise, false.
        /// </returns>
        private static bool AreEqual<T, TMember>(
            T first,
            T second,
            Func<T, ReadOnlyCollection<TMember>> reader,
            Func<TMember, TMember, bool> comparer = null)
        {
            if (null == comparer)
                comparer = (x, y) => EqualityComparer<TMember>.Default.Equals(x, y);

            ReadOnlyCollection<TMember> firstCollection = reader(first);
            ReadOnlyCollection<TMember> secondCollection = reader(second);

            if (null == firstCollection || null == secondCollection)
            {
                return firstCollection == secondCollection;
            }

            return !firstCollection.Where((t, i) => !comparer(t, secondCollection[i])).Any();
        }

        /// <summary>
        /// Fails the comparison operation, setting the outcome of the comparison to be that the
        /// two expression trees are "not equal", as well as returning an <see cref="Expression"/>
        /// value which, if returned by a visitor operation, will result in all operations coming
        /// to a stop.
        /// </summary>
        /// <param name="node">The current node being visited.</param>
        /// <returns>
        /// An <see cref="Expression"/> value which should be returned by the calling visitor
        /// operation.
        /// </returns>
        private Expression Fail(Expression node)
        {
            ExpressionsAreEqual = false;

            return node;
        }
    }

What our ExpressionComparison visitor does walk down a provided expression tree while comparing each node it encounters with nodes from another tree that are stored in a queue. The queue is created through the use of another visitor known as an ExpressionCollection, which basically converts an expression tree into an IEnumerable<T> sequence of the nodes found on that tree. The code for that class will be provided at the end of this article.

In each visitor method, certain data points are compared between the two comparand nodes. If any points of data do not match, we fail the comparison check by setting the outcome of the check to false and aborting our walk.

As you may have already known, we saw additional types of Expression nodes added to .NET Framework 4.0. Our visitor overrides almost all possible overrides in order to compare every type of node possible. The ExpressionComparison type, as it is presented, should be able to support any expression tree found in the universal set of all possible expression trees.

How can this be true if we don’t override all possible Visit* methods? Well, we don’t need to; not all Expression object types have data unique to their class. Many Expression object types also simply contain other Expression instances, which are taken care of by the more general visitor overrides when walking further down the tree anyways.

A Visitor To Collect Expressions: ExpressionCollection

Briefly referenced in the last section, we also employ a simple expression visitor that will take an expression tree and provide all nodes belonging to that tree in the form of an IEnumerable<T> sequence. The code for that will now be provided:

ExpressionCollection.cs

    /// <summary>
    /// Provides an <see cref="IEnumerable{Expression}"/> created by walking through an expression
    /// tree.
    /// </summary>
    public sealed class ExpressionCollection : ExpressionVisitor, IEnumerable<Expression>
    {
        private readonly List<Expression> _expressions = new List<Expression>();

        /// <summary>
        /// Initializes a new instance of the <see cref="ExpressionCollection"/> class.
        /// </summary>
        /// <param name="expression">
        /// The expression tree to walk when populating this collection.
        /// </param>
        public ExpressionCollection(Expression expression)
        {
            Visit(expression);
        }

        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }

        /// <inheritdoc/>
        public IEnumerator<Expression> GetEnumerator()
        {
            return _expressions.GetEnumerator();
        }

        /// <summary>
        /// Processes the provided <see cref="Expression"/> object by adding it to this collection
        /// and then walking further down the tree.
        /// </summary>
        /// <param name="node">
        /// The expression to process to add to this collection and walk through.
        /// </param>
        /// <returns>
        /// The modified expression, assuming the expression was modified; otherwise, returns the
        /// original expression.
        /// </returns>
        public override Expression Visit(Expression node)
        {
            if (null != node)
                _expressions.Add(node);

            return base.Visit(node);
        }
    }

In the next article, we can talk about the ExpressionHashCodeCalculator, if I get around to posting it!

© 2012-2013 Matt Weber. All Rights Reserved. Terms of Use.