Anyway, I don’t want to rant about bettermarks. On the contrary, I think bettermarks is great. But I’m worried about the content of math classes. The content that is specified by politicians. 7th-grade students in Germany seem to constantly deal with units in math. I guess the correct English term is “physical units”. Physical units because units are a concern of physics and, more importantly:

Mathematics is not concerned with units.

That’s the whole point of mathematics: You make things simple so you can handle them. In mathematics, there is no unit of area and unit of length.
Mathematicians are happy if something can be measured at all, a property that not too many mathematical entities have.

Take fractals for example: Suppose I drew a Sierpinski
Triangle on a piece of paper, how much space do I need to do that?
Obviously, I will need some space if I wanted to actually draw it (physical reality), otherwise I couldn’t see it. Mathematically speaking, however, it has Lesbegue measure 0 and thus, vanishing area. Not square kilometers, apples or Newton, just a number.

How about a Hilbert Curve? I can draw an approximation on some finite area. Now I can refine it, thereby increasing its length, but I don’t need to extend my drawing. Eventually, the length will grow to infinity – how can this be? In the context of soccer fields and living rooms, this doesn’t make sense – it’s purely theoretical. It’s mathematics.

I agree, it is important to teach children about the typical size of a living room, a soccer field or the distance between some well-known cities. But that shouldn’t be done in mathematics: Mathematics should be concerned with abstract thinking only. Many people believe abstract thinking makes classes less appealing to children, but honestly: Do they really think that “Martha owns a set of Miley Cyrus stickers of cardinality 8″ type of exercises make math more interesting, let alone be taken seriously by children?

It’s actually in the manual so this is not exactly a secret, but I managed to overlook it so perhaps I’m not the only one…

In our specific scenario, db4o was about 3 times slower than MSSQL via Linq to SQL in the past days.

Just a few minutes ago, I finally read this:

Native Query optimizer for .NET requires the following libraries to work:
Db4obects.Db4o.Instrumentation.dll
Db4objects.Db4o.NativeQueries.dll
Mono.Cecil.dll
Cecil.FlowAnalysis.dll

(see http://developer.db4o.com/Documentation/Reference/db4o-7.12/net35/reference/html/reference/tuning/native_query_optimization.html)

I added these dll’s to my solution and wooosh! Now it’s up to 50 times faster than before! That’s what I needed… Will see how this works with larger data sets…

There has been some discussion over at stackoverflow on setting a default route to an area in mvc, so I want to post some very crude, but working example code here… I will write some explanatory text here if I find the time.

I feel that the fact that the order of operation in Application_Start() matters is quite problematic, but that has been discussed elsewhere (I’ll be searching for the link…) Anyway, when registering the areas first, the default route can be set to an area.

        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            RegisterRoutes(RouteTable.Routes);
        }

In the AreaRegistration,

        public override void RegisterArea(AreaRegistrationContext context)
        {
            context.MapRoute(
                "ShopArea_default",
                "{controller}/{action}/{id}",
                new { action = "Index", id = "", controller = "MyRoute" },
                new { controller = "MyRoute" }
            );
        }

will do the job. Note the use of the constraint that will only accept requests to the areas’ controller that should be used as a default.

This is a working solution, but I think it is quite error-prone and not very elegant. In the meantime, I started to use MvcContrib, because it’s portable areas are really smart, make deployment easier and foster reusability of the code, and the views.

Lately, I have fiddled around with Versant’s excellent dual-license object database db4o a little and I think object databases are very neat. In fact, I read a few pages in PoEAA [Patterns of Enterprise Application Architecture] today, and here and there Fowler writes how cool object databases are. The Fowler knows!

Well, anyhow when you download db4o (sign up and go for the latest release) there is no standalone server application included. That makes perfect sense, because the server needs access to your domain model / data model dll. In an object database, there are no tables, but there are objects, so you have to compile them into the application that runs the actual db4o server. There is server code which handles practically everything that is tricky, but it’s in a dll so you’ll have to write a few lines to build an application out of it. I figured this would be a great time to write my first windows service and so I mashed up some code I found on the net.

I initially thought the VS 2008 designer would set up pretty much everything, but it turned out that things are a little more complicated.

The Installer

Since a service will run in a different manner, potentially using a different user account, etc. it needs to be installed first. There is a tool called installutil.exe, but using it is a little awkward. Also, you’d have to deploy it along your application. Matt Davis posted a cool guide on stackoverflow and some additional information here on how to write a windows service that is esentially able to install itself!

Unexpected Features

One of the most peculiar features is that -should you prefer to have your own event log instead of writing to the ApplicationLog- you have to search through a tree of installers, find the EventLogInstaller and modify it instead of simply adding a new one because the ServiceInstaller will come along with the EventLogInstaller as a child:

EventLogInstaller installer = FindInstaller(this.Installers);
if (installer != null)
    installer.Log = ServiceConfiguration.LogName;

We also need to take care of spawning the actual worker thread, but fortunately there is a comprehensive guide on MSDN explaining this.

Using the Sample

First things first: Of course, this is not nearly production-safe code! Also, I did not include the db4o dll’s because I’m not sure about the licence terms.

The installer in 'action'. Note the Administrator prompt

1. Download the sample, extract
2. Download db4o, install
3. Copy Db4objects.Db4o.dll and Db4objects.Db4o.CS.dll from the db4o install directory to the samples’ lib directory
4. Compile
5. Open an Administrator command prompt and find the sample’s bin folder. There is no feedback in case anything goes wrong (at best, the program crashes)
6. Call the install routine by executing emphess.db4oServer.exe -install. This will install the db4o server and the associated event log. The server will not be started automatically.
7. Head over to services.msc or your EventLog, where you should find a new entry!
8. Edit the configuration file, ready to run!
9. Don’t use this for anything production…

The App.Config

The configuration file looks like this

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="UseLocalFile" value="false" />
    <!-- <add key="DatabaseLocalFileName" value="irrelevant"/> -->
    <add key="DatabaseHost" value="localhost" />
    <add key="DatabasePort" value="52354" />
    <add key="DatabaseServerFileName" value="C:/Development/db4oServer/db/server.db4o" />
    <add key="DatabaseUser" value="test" />
    <add key="DatabasePassword" value="test" />
  </appSettings>
</configuration>

The UseLocalFile setting is meant for clients so you can easily switch between file-based and network-based configurations. Since db4oServer.Shared contains a small class that holds this configuration data, you can easily reuse the code in a different app, e.g. in the client.

Todo-List

There are some things I’d like to add over the next weeks, so I put the list here to give me some ‘pseudo-extrinsic motivation’… (yes, I like complicated words)

• Simple sample client
• Out-of-band data for backup, defragmentation commands, etc.
• Tests / Benchmarks

I hope you have any use for this.

Not so delicious

I want to store some bookmarks online. period. Do they really think I’ll signup for a yahoo mail account (given that I already have a dozen accounts anyway?) Why does one need two secret questions? Secret questions are stupid in my eyes anyhow, but in times of facebook, knowing one’s mothers maiden name does not mean anything… Anyway, can somebody recommend a (good) online bookmarking service? yeah, I know, shouldn’t be too hard to find, hm? I better get some sleep…

However, when using shared hosting there are some pitfalls. I just trapped into the “Unable to locate WordPress Content directory (wp-content).” error. Here’s what I did:
My web hoster allows many FTP logins, so I created one especially for WordPress and set its ftp root to the WordPress root
It seems that the error message is a little misleading, because it turned out that access to the temp-directory was the actual problem. In this post, user lightwolf posted a workaround:

putenv('TMPDIR=' . ini_get('upload_tmp_dir'));

Added to wp-config.php.

This fixed my problem.

A very basic, but rather exact profiler. It uses QueryPerformanceCounter. Perhaps I shouldn’t even call this profiler, because a profiler typically keeps track of the parts of code it measures. So let’s call it a precise stopwatch. Well, anyways, here’s the code:

using System.Runtime.InteropServices;

namespace SimpleProfiler
{
    public class Profiler
    {
        long mFrequency;

        long mAccumulatedTime;
        long mStartTime;
        long mEndTime;

        long mLastTime;

        bool mInitialized = false;
        bool mRunning = false;

        public Profiler()
        {
            mInitialized = QueryPerformanceFrequency(out mFrequency);
        }

        public bool StartMeasure()
        {
            if (mInitialized && !mRunning)
            {
                mRunning = true;
                return QueryPerformanceCounter(out mStartTime);
            }

            return false;
        }

        public bool StopMeasure()
        {
            if (mInitialized && mRunning)
            {
                mRunning = false;
                bool bSuccess = QueryPerformanceCounter(out mEndTime);

                if (bSuccess)
                {
                    mLastTime = mEndTime - mStartTime;
                    mAccumulatedTime += mLastTime;
                    return true;
                }
            }

            return false;
        }

        public double GetLastTime()
        {
            return (double)((double)mLastTime / (double)mFrequency);
        }

        public double GetAccumulatedTime()
        {
            return (double)((double)mAccumulatedTime / (double)mFrequency);
        }

        [DllImport("kernel32.dll")]
        private static extern bool QueryPerformanceCounter(out long count);

        [DllImport("kernel32.dll")]
        private static extern bool QueryPerformanceFrequency(out long frequency);
    }
}

which is also contained in the source code for the previous article.

Part II of the article will show how a SerializationSurrogate works and explore wheter we can use it for generic de-serialization of DependencyProperties. Also, in this article I provide full source code for both parts of the article.

UPDATE: A much better version of this article can now be found at the CodeProject: DependencyProperty Serialization for Business Objects

Alternatively, directly get the source code here: http://www.emphess.net/wp-content/uploads/2009/03/bpboserialization1.zip

Well, let’s get started:

ISerializationSurrogate

This interface is designed as a stand-in for your class upon serialization and de-serialization.

It is quite simple and contains only two methods:

public void GetObjectData(object obj, SerializationInfo info, StreamingContext context)

and

public object SetObjectData(object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)


This is quite interesting, since there is an explanation on MSDN why they chose not to provide a SetObjectData() method for the ISerializable interface, so this makes quite a difference.

Surrogate Serialization

For serialization, we use almost the same code we used in part I, with a few modifications only:

public void GetObjectData(object obj, SerializationInfo info, StreamingContext context)
{
    PropertyDescriptorCollection descriptors = TypeDescriptor.GetProperties(obj.GetType(),
            new Attribute[] { new PropertyFilterAttribute(PropertyFilterOptions.SetValues |
                                                          PropertyFilterOptions.UnsetValues |
                                                          PropertyFilterOptions.Valid ) });

    List<FieldInfo> fieldInformation = ReflectionHelper.GetFieldInformation(obj.GetType());

    foreach (FieldInfo fiRover in fieldInformation)
    {
        object[] attribs = fiRover.GetCustomAttributes(typeof(NonSerializedAttribute), false);

        if (attribs.Length > 0)
            continue; // Don't serialize this

        info.AddValue(fiRover.Name, fiRover.GetValue(obj));
    }

    foreach (PropertyDescriptor propertyDescriptor in descriptors)
    {
        SerializeProperty(obj, info, propertyDescriptor);
    }
}

(Please note that I clean the code up a little, in the source download there is a lot of debugging output, etc.)

Surrogate De-Serialization

Now, it seems as if an implementation of ISerializationSurrogate might do the job and help us to circumvent the necessity to provide boring constructors through the SetObjectData() method. So let’s give it a try by basically using the deserialization code from part I:

public object SetObjectData(object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)
{
    Type thisType = obj.GetType();
    DependencyObject depObj = obj as DependencyObject;

    // De-Serialize Fields
    List<FieldInfo> fieldInformation = ReflectionHelper.GetFieldInformation(thisType);

    foreach (FieldInfo fiRover in fieldInformation)
    {
        object[] attribs = fiRover.GetCustomAttributes(typeof(NonSerializedAttribute), false);

        if (attribs.Length > 0)
            continue; // Don't deserialize this

        fiRover.SetValue(obj, info.GetValue(fiRover.Name, fiRover.FieldType));
    }

    // De-Serialize DependencyProperties
    PropertyDescriptorCollection descriptors = TypeDescriptor.GetProperties(thisType,
            new Attribute[] { new PropertyFilterAttribute(PropertyFilterOptions.SetValues |
                                                          PropertyFilterOptions.UnsetValues |
                                                          PropertyFilterOptions.Valid ) });

    // Try to use a mapping to set all DP values deferred. This will actually just
    // postpone the Exception
    List<DependencyValueMap> mappingList = new List<DependencyValueMap>();

    foreach (PropertyDescriptor propertyDescriptor in descriptors)
    {
        if (propertyDescriptor.Attributes[typeof(NonSerializedAttribute)] == null)
        {
            DependencyProperty dp = DependencyPropertyHelper.FindDependencyProperty(obj, propertyDescriptor.Name);

            if (null != dp)
            {
                mappingList.Add(new DependencyValueMap(dp, obj as DependencyObject, info.GetValue(propertyDescriptor.Name, propertyDescriptor.PropertyType)));
            }
            else
            {
                throw new SerializationException(String.Format(@"Failed to deserialize property '{0}' on object of type '{1}'.
Property could not be found. Version Conflict?", propertyDescriptor.Name, thisType));
            }
        }
    }

    foreach (DependencyValueMap dvRover in mappingList)
    {
        // This call will cause an InvalidOperationException:
        depObj.SetValue(dvRover.dp, dvRover.value);
    }

    return null;
}

Now, unfortunately, we cannot set the values of these DependencyProperties. The SetValue() method in DependencyObject will throw the oh-so-magic InvalidOperationException. I haven’t been able to find a way to go around this.

Summing it up

Well, that’s it basically. Where are we now?

• It is possible to use DependencyProperties for business objects and serialize and deserialize them.
• A reflection-based base class “SerializableDependencyProperty” does the job, as long as you stick to the naming convention and implement the deserialization constructor in all derived classes
• Circumventing the explicit deserialization constructor seems impossible due to limitations of the DependencyObject base class

The Source

The sample solutions contains two projects:
WPFDependencyPropertySerialization shows how the serialization of part I can be accomplished.
WPFDependencyPropertySerializationError shows the extension using an ISerializationSurrogate and, as mentioned before, will lead to an Exception … which will not be caught so you can really feel it rumbling:
“Current local value enumeration is outdated because one or more local values have been set since its creation.”

You can download the source at http://www.emphess.net/wp-content/uploads/2009/03/bpboserialization1.zip

Have Fun!

A post scriptum on DependencyProperties for business entities

The project I’m currently working on comes with a very complex data structure. It consists of a set of trees which can be connected in various different ways. We also have to account for circular dependencies between these objects. The user can create and modify all these different types of connections.
Moreover, the architecture of the application is highly sophisticated and is based on Microsoft’s composite application guidance. A lot of modules interact with each other, each having their own data, similar to a ViewModel yet managed by a Presenter. What sounds a little messy has been proven to be the best solution in a number of discussions.
These business entities are based on DependencyProperties and a lot of crucial features depend on the functionality provided by the DependencyProperties. It works well, though I should mention that I did not use a number of DependencyProperty features in the first place. For example, coercion and validation coupled with automated de-serialization might lead into trouble, so keep this in mind should you ever intend to go down the path…

In this article, we’ll explore if and how reflection magic can assist us in doing it anyway, how we can locate DependencyProperties via reflection and what pitfalls remain. Moreover, I’ll give an outlook why the most desireable solution (that almost suggests itself) fails.

Using DPs in your business logic layer is a disputable decision. The application I work on has very unsual demands and I am still happy with the decision I made. I don’t want to discuss that here, though, since it is out of scope.

The Issue

When serializing objects, you can prevent certain properties from being serialized using the [NonSerialized] property, but if the base class is not marked as [Serializable], such as the DependencyObject class, attempting to serialize will throw an exception.

However, implementing ISerializable manually does the job:

[Serializable]
public class SerializableDependencyObject : DependencyObject, ISerializable
{
    // Note that this does not call base(info, context) since the base class does not have
    // a deserialization constructor
    public DagNode(SerializationInfo info, StreamingContext context)
    { }

    // again, the base class is not an ISerializable
    public virtual void GetObjectData(SerializationInfo info,
                                                 StreamingContext context)
    {}
// ...
}

What bugs me, however, is that now, all derived classes need to implement GetObjectData and the deserialization constructor explicitly, producing both stupid and error-prone code:

public class StupidClass : SerializableDependencyObject
{
  #region ISerializable Members
  public virtual void GetObjectData(SerializationInfo info, StreamingContext context)
  {
    info.AddValue("PropertyA", mPropertyA);
    info.AddValue("PropertyB", mPropertyB);
    info.AddValue("PropertyC", mPropertyC);
  }

  public StupidClass (SerializationInfo info, StreamingContext context)
  {
    mPropertyA = info.GetDouble("PropertyA");
    mPropertyB = info.GetDouble("PropertyB");
    mPropertyC = info.GetDouble("PropertyC");
  }
  #endregion
}

We obviously don’t want this, since it produces a lot of manually written, error-prone code that needs to be adjusted constantly when code changes are made – a lot of work when you consider we’re not necessarily adding functionality yet.

One Step Back: .NET Serialization

It took me some time to realize that .NET has quite a number of techniques aimed at serialization. The process is described quite well at http://msdn.microsoft.com/en-us/library/tyf8zbfk.aspx, but it is still simplified since there are serialization attributes introduced in .NET 2.0 that allow you to hook up additional methods during the serialization/deserialization process:
“If the class being deserialized implements the IDeserilizationCallback, the OnDeserialization method is automatically called when the entire object graph has been deserialized.” (see http://msdn.microsoft.com/en-us/library/ty01×675(VS.71).aspx)

These concepts are somewhat different and allow you to control the process of serialization and deserialization to a certain degree.
You might be tempted to ask: “Why should I worry about .NET serialization if it is this complicated – isn’t it easier to do it myself?”, but the answer is probably “no”, since the BinaryFormatter really solves all the itty-gritty problems for you in a convenient manner. These are:

• Solving dependency chains and circular links
• Creating unique identifier and associating them w/ object instances
• Serializing generic containers
• Constructing objects on de-serialization and re-assigning pointers

All this does not help in serializing DependencyProperties, however, since your owning class is derived from DependencyObject, that is not marked as [Serializable] – unless you want to do it manually in each derived class.

An intelligent base class

How about a very intelligent base class that uses reflection to mimick the behaviour we’d expect?

We’d certainly need a class that is responsible for this behaviour, we might want to call it SerializableDependencyObject again:

[Serializable]
public class SerializableDependencyObject : DependencyObject, ISerializable
{
}

Now, the class needs to implement ISerializable in a sufficient manner, that is, in such way that derived classes behave just like normal serializable classes:

• The value of DependencyProperties is being stored and restored automatically
• DependencyProperties marked as [NonSerialized] are not being serialized

The GetObjectData method

Let’s try to fetch all fields and properties from the current object instance (this) in the base class. We want to add all these fields to the SerializationInfo instance:

public void GetObjectData(SerializationInfo info, StreamingContext context)
{
  PropertyDescriptorCollection descriptors = TypeDescriptor.GetProperties(GetType(),
        new Attribute[] {
            new PropertyFilterAttribute(PropertyFilterOptions.SetValues |
                                        PropertyFilterOptions.UnsetValues |
                                        PropertyFilterOptions.Valid ) });

  List<FieldInfo> fieldInformation =
    ReflectionHelper.GetFieldInformation(GetType());

  foreach (FieldInfo fiRover in fieldInformation)
  {
    object[] attribs =
      fiRover.GetCustomAttributes(typeof(NonSerializedAttribute), false);

    if (attribs.Length > 0)
      continue; // Don't serialize this

    info.AddValue(fiRover.Name, fiRover.GetValue(this));
  }

  foreach (PropertyDescriptor propertyDescriptor in descriptors)
  {
    if (propertyDescriptor.Name == "Dispatcher" ||
        propertyDescriptor.Name == "DependencyObjectType" ||
        propertyDescriptor.Name == "IsSealed" )
          continue;

      SerializeProperty(info, propertyDescriptor);
  }
}

The first loop of the method will serialize all fields, resembling the functionality we have when not implementing ISerializable manually. The second part, adding functionality, cares for DependencyProperties. The ReflectionHelper is just a simple wrapper around the System.Type.GetFields() method with some performance improvements and minor tweaks.

Let’s have a look at the serialization constructor of SerializableDependencyObject:

public SerializableDependencyObject(SerializationInfo info,
                                     StreamingContext context)
{
    Type thisType = GetType();

    // De-Serialize Fields
    List<FieldInfo> fieldInformation =
        ReflectionHelper.GetFieldInformation(thisType);

    foreach (FieldInfo fiRover in fieldInformation)
    {
        object[] attribs =
          fiRover.GetCustomAttributes(typeof(NonSerializedAttribute), false);

        if (attribs.Length > 0)
            continue; // Don't try to deserialize this

        fiRover.SetValue(this, info.GetValue(fiRover.Name, fiRover.FieldType));
    }

    // De-Serialize DependencyProperties
    PropertyDescriptorCollection descriptors = TypeDescriptor.GetProperties(thisType,
        new Attribute[] {
           new PropertyFilterAttribute(PropertyFilterOptions.SetValues |
                                       PropertyFilterOptions.UnsetValues |
                                       PropertyFilterOptions.Valid) });

    foreach (PropertyDescriptor propertyDescriptor in descriptors)
    {
        if (propertyDescriptor.Name == "Dispatcher" ||
            propertyDescriptor.Name == "DependencyObjectType" ||
            propertyDescriptor.Name == "IsSealed")
            continue;

        DependencyProperty dp =
          DependencyPropertyHelper.FindDependencyProperty(this, propertyDescriptor.Name);

        if (null != dp)
            SetValue(dp, info.GetValue(propertyDescriptor.Name, propertyDescriptor.PropertyType));
        else
            throw new SerializationException(String.Format(@"Failed to deserialize
            property '{0}' on object of type '{1}'. Property could not be found.
            Version Conflict?",
            propertyDescriptor.Name, thisType));
    }
}

Again, the first loop handles simple fields while the second part adds functionality for DependencyProperties. One line in the second part deserves some attention:

DependencyProperty dp =
  DependencyPropertyHelper.FindDependencyProperty(this, propertyDescriptor.Name);

Remember DependencyProperties are static members which are registered in some application-wide registry, for example:

public static DependencyProperty NameProperty =
DependencyProperty.Register("Name",
                            typeof(string),
                            typeof(GraphNode),
                            new PropertyMetadata(String.Empty));

Unfortunately, there is no DependencyProperty.Find() method. That is where the DependencyPropertyHelper comes into play:

class DependencyPropertyHelper
{
    /// <summary>
    /// Finds a dependency property on an object by its name.
    ///
    /// Motivation: There is no accesible DP registry. When creating DPs, one must register them using
    /// DependencyProperty.Register(), but there is no DependencyProperty.FindProperty()
    /// </summary>
    /// <param name="_object">The object that supposedly has a property of the supplied name</param>
    /// <param name="_propertyName">The name of the property to find, e.g. "Height". NOTE: The corresponding property is expected to be named "HeightProperty" in this case.</param>
    /// <returns></returns>
    public static DependencyProperty FindDependencyProperty(object _object, string _propertyName)
    {
        if (null != _object && !String.IsNullOrEmpty(_propertyName))
        {
            Type typeAttachedTo = _object.GetType();
            FieldInfo fi = null;

            while (null == fi && typeAttachedTo != null)
            {
                fi = typeAttachedTo.GetField(_propertyName + "Property");
                typeAttachedTo = typeAttachedTo.BaseType;
            }

            if (null != fi)
            {
                return fi.GetValue(null) as DependencyProperty;
            }
        }
        return null;
    }
}

First results

At this point, we can supply a base class SerializableDependencyObject that allows simple serialization of DependencyObjects with their associated DependencyProperties. However, quite a number of dangerous pitfalls remain:

• Setting DependencyValues can be problematic: We might trigger callbacks (PropertyChangedCallbacks, CoerceValueCallback)
• Triggered callbacks might rely on yet unitialized data
• We rely on the “Property” naming convention (e.g. the DP of property "Name" is called "NameProperty")
• You need to define a deserialization constructor for each and every derived class which needs to call the base class’ deserialization constructor. Failing to do so throws a run-time exception.
• The current code does not handle versioning

Outlook

Serializing dependency properties is indeed cumbersome. However, INotifyPropertyChanged might not be an alternative, and reinventing the wheel might not be desirable either. While basic functionality of DependencyProperties is probably quickly implemented, there are some obvious drawbacks, first and foremost the integration with other components that simply require a DependencyObject to work with.

Synchronizing a complex DataModel with sets of equally complex ViewModels can be a pain, too, so for those having such unusual demands, it’s their time to choose their poison.

In the second part, we’ll have a look at the ISerializationSurrogate interface and why we can’t implement it the same way we implemented the SerializableDependencyObject. We will also make the acquaintance of an infamous InvalidOperationException: “Current local value enumeration is outdated because one or more local values have been set since its creation.” which esentially keeps us (and probably microsoft) from implementing it just the way we did in here.

Anyway, I stumbled over some strange bug this morning that turned out to be related to the GC. But let’s just step back a minute:

The application I currently work on is based on CompositeWPF . I added a very simple module to the application, a simple passive debugging module. I called it “InspectorModule”. The InspectorPresenter now listens for global modifications to the business object which is kept by the BusinessEntityManager:

public InspectorPresenter(IInspectorView _view,
            IEventAggregator _eventAggregator,
            IBusinessEntityManager _businessEntityManager)
{
    mView = _view;
    mEventAggregator = _eventAggregator;
    mBusinessEntityManager = _businessEntityManager;

    mEventAggregator.GetEvent<BusinessInstanceInvalidatedEvent>().Subscribe(ReloadInspector);
}

Now, upon each modification of the business object, ReloadInspector shall be called. So, starting the application and triggering the event — nothing happened. The ReloadInspector method is not being called. Why?

After some debugging, it suddenly worked – the only problem being: I didn’t actually change anything!

To make a long story, I realized the CompositeWPF DelegateReferenceclass keeps a WeakReference to the object (the InspectorPresenter, in this case) when registering it via the EventAggregator as above.

Unfortunately, due to the simplicity of the InspectorPresenter, no instantiated object actually keeps a reference to the Presenter (apart from the WeakReference of the event which, by definition, does not prevent it from being finalized).

That’s why the object is being finalized and the event never fires. Actually, on the first call of the associated Publish() method, the Composite WPF-Internal EventBase.PruneAndReturnStrategies() will remove it from the list after it’s associated Action is supposedly null.

Debugging this was quite cumbersome, and the solution of striking simplicity: I simply continued to develop the “Inspector”, a little more than I originally planned, so the user can now select an object in the inspector. Now, I have a simple event like this:

public InspectorPresenter(IInspectorView _view,
            IEventAggregator _eventAggregator,
            IBusinessEntityManager _businessEntityManager)
{
    // ...
    mView.SelectedNodeChanged += new OnSelectedNodeChanged(mView_SelectedNodeChanged);
    // ...
}

This keeps a (strong) reference to the Presenter, and the GC does not kill my presenter anymore! The reason it worked when debugging, I guess, is that the debugger will keep the GC from finalizing objects under certain circumstances.