Fortunately, various approaches exist to help mitigate this complexity in different situations. Often, the Model’s hierarchical structure is formed by Model elements having collections of child Model elements. For example, an address book might have a collection of contacts, which in turn have collections of addresses and phone numbers. In the approach I describe here, the complexity of such a hierarchical Model is managed through collection transforms. A collection transform “transforms” a source collection into a readonly target collection and keeps itself up-to-date based on collection change notifications from the source collection. In a sense, this is similar to the Select extension method provided by Linq, except that future changes to the source collection are reflected in the target (transformed) collection. When this approach is applied to hierarchical ViewModels, the individual ViewModel elements (the address book, the individual contacts, and the individual addresses) can be changed through the ViewModel, but the overall structure of the ViewModel hierarchy can only be affected by the structure of the Model hierarchy. In practice, this is both functional and simple to implement.

The first thing needed is the TransformedCollection class. This is a readonly collection that supports change notifications:

This is a generic, ReadOnlyCollection with type parameters for the type of element in the source collection (the Model in our case) and the type of element in the target collection (the ViewModel in our case). The constructor takes the source collection, a delegate that transforms a source element into a target element, and an optional delegate that cleans up target elements when they are removed (such as disposing them, if necessary). The sample code has the full implementation.

The simplest way to use this class is to use it directly (do not subclass it). This scenario can further be simplified with an extension method:

Using the TransformedCollection directly works well when the ViewModel classes do not have corresponding interfaces. For example, consider the following (simplified) data model:

A corresponding ViewModel might look like:

If the ViewModel classes have corresponding interfaces, the situation is slightly more complex, but certainly manageable:

In both cases above, the ViewModel should dispose the TransformedCollection instance at some point, but I omitted this for clarity. The sample code properly disposes the TransformedCollections.

The fact that the TransformedCollection is readonly may seem like a limitation that would be difficult to work with, but in practice I’ve found it to reduce complexity at a negligible cost. Since the ViewModel references to the Model, it’s easy enough for the ViewModel to expose commands that affect the underlying Model which is in turn reflected in the ViewModel. For example, an AddContactCommand exposed by the AddressBookViewModel can add a Contact to the underlying AddressBook, which is then reflected in the AddressBookViewModel’s ContactViewModelCollection. Again, this is demonstrated in the sample code. As always, feedback is welcome.

Hosting PowerShell is a bit more complex than hosting Iron Python, primarily due to PowerShell’s lack of support for .NET generics and MEF’s lack of non-generic methods on the CompositionContainer class (particularly GetExportedValue). We can overcome this by taking advantage of PowerShell’s Extended Type System (ETS). The first thing needed though is some extension methods for CompositionContainer that provide non-generic versions of GetExportedValue and GetExportedValues:

Next, we’ll need an extension method to make it easier to get the underlying .NET object wrapped by PowerShell’s PSObjects:

The PowerShell scripting service takes advantage of the above extension methods and the PowerShell ETS:

Notice that the CompositionContainer is wrapped in a PSObject. This allows us to use the PowerShell ETS to add non-generic versions of the GetExportedValue and GetExportedValues methods to the CompositionContainer, which are significantly easier to invoke from a PowerShell script. The non-generic GetExportedValue and GetExportedValues implementations use the extension methods we previously defined.

Also notice that the Runspace’s ThreadOptions is explicitly set to use the current thread. This is a crucial step. Without this, PowerShell will use a separate thread for the RunSpace (not the UI thread) and therefore scripts will not be able to interact with the UI.

Finally, notice that we capture only the last PSObject from the Pipeline’s Invoke method. Invoke returns all objects that are output to the host. Capturing only the last one is analogous to the way the last value output from PowerShell functions (implicitly, or explicitly by using a return statement) is the value returned from the function. Also note that only the underlying .NET object of the PSObject is returned, which is probably desirable to the caller of the RunScript method.

I’ve made some sample code available that demonstrates this approach. The focus is definitely on the PowerShell scripting, so the rest of the application is very simple and rather poorly designed. Using PowerShell's ETS to add non-generic CompositionContainer methods was the cleanest approach I could find. If anyone has an alternative approach, I'd love to hear about it.

Scriptable applications require careful design that programmatically exposes components of the application to scripts. MEF (Managed Extensibility Framework), introduced in .NET 4.0 (under System.ComponentModel.Composition), promotes such a design. Typically, MEF-based applications are compositions of highly cohesive, loosely coupled components. In the approach I describe here, the entire CompositionContainer is exposed to the scripts, and therefore all components of the application are exposed. Scripts are treated as transient entities and query the CompsoitionContainer directly. These days, there are many .NET compatible scripting languages, but in this post I’ll specifically be using Iron Python since hosting it in an application is trivial.

The first thing needed is an interface for components that run scripts:

public interface IScriptingService
{
    object RunScript(string script);
}

Eventually, some UI in the application might consume this interface to allow the user to run scripts saved on disk, or perhaps would expose an interactive console within the application. Following is an implementation of this interface that supports Python scripting:

[Export(typeof(IScriptingService))]
internal class PythonScriptingService : IScriptingService
{
    [Import]
    private CompositionContainer container;

    public object RunScript(string script)
    {
        ScriptEngine pythonEngine = Python.CreateEngine();
        ScriptScope scriptScope = pythonEngine.CreateScope();
        scriptScope.SetVariable("container", this.container);

        ScriptSource scriptSource = pythonEngine.CreateScriptSourceFromString(script);
        return scriptSource.Execute(scriptScope);
    }
}

Notice that the implementation imports the CompositionContainer. For this to work, the CompositionContainer basically needs to export itself. This can be done imperatively as follows:

var batch = new CompositionBatch();
batch.AddExportedValue<CompositionContainer>(container);
container.Compose(batch);

The PythonScriptingService exposes the CompositionContainer to scripts as a variable named container. Scripts can query the container for exports and use them to extend or automate the application’s functionality. As a simple example, a Python script might look something like this:

import clr
clr.AddReference("SampleApplication")
from SampleApplication import IStatusService
statusService = container.GetExportedValue[IStatusService]()
statusService.ReportStatus("Hello from python!")

If you have multiple implementations of IScriptingService for different scripting languages, it might make sense to add ExportMetadata to each implementation that describes the scripting language supported by the implementation and perhaps the file extension used for that scripting language. This will of course depend on the specific application implementing and exposing these services.

Also worth noting, it might be possible to use a custom MEF programming model to inject components directly into the scripts as opposed to the scripts relying on direct access to the CompositionContainer. This would certainly be more complex and require more code, but it’d be interesting to explore regardless.  If anyone has done something like this or has ideas around this, I’d love to hear about it!

I’ve made some sample code available that demonstrates this approach. The focus is definitely on the Iron Python scripting, so the rest of the application is very simple and rather poorly designed. Feedback is welcome.

MEF (Managed Extensibility Framework), introduced in .NET 4.0 (under System.ComponentModel.Composition), provides a powerful framework for creating extensible applications. Traditionally, extensible applications have a large and often fixed core with specific extension points to allow the application to be extended in very particular ways. While limited extensibility is sometimes preferred, it is often desirable to maximize extensibility. When used to its fullest, MEF allows an application to be almost entirely composed of loosely coupled components. With such a design, core components and extensions become one and the same. In the approach I discuss here, the only remaining fixed aspect of the application is the bootstrapper. The bootstrapper is responsible for the following:

1. Preparing the part catalog (ComposablePartCatalog) and initializing the container (CompositionContainer)
2. Discovering and executing the pseudo entry points

<TypeCatalog
    xmlns="clr-namespace:System.ComponentModel.Composition.Hosting;assembly=System.ComponentModel.Composition"
    xmlns:sys="clr-namespace:System;assembly=mscorlib"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <x:Arguments>
    <x:Array Type="sys:Type">
      <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartA, PartLibrary1" />
      <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartB, PartLibrary1" />
      <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartC, PartLibrary2" />
      <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartD, PartLibrary2" />
    </x:Array>
  </x:Arguments>
</TypeCatalog>

Alternatively, the two might be combined with an AggregateCatalog as follows:

<AggregateCatalog
    xmlns="clr-namespace:System.ComponentModel.Composition.Hosting;assembly=System.ComponentModel.Composition"
    xmlns:sys="clr-namespace:System;assembly=mscorlib"
    xmlns:mefp="clr-namespace:System.ComponentModel.Composition.Primitives;assembly=System.ComponentModel.Composition"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <x:Arguments>
    <x:Array Type="mefp:ComposablePartCatalog">

      <AssemblyCatalog x:Arguments="MyApplication.exe" />

      <TypeCatalog>
        <x:Arguments>
          <x:Array Type="sys:Type">
            <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartA, PartLibrary1" />
            <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartB, PartLibrary1" />
            <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartC, PartLibrary2" />
            <sys:Type x:FactoryMethod="sys:Type.GetType" x:Arguments="PartD, PartLibrary2" />
          </x:Array>
        </x:Arguments>
      </TypeCatalog>

    </x:Array>
  </x:Arguments>
</AggregateCatalog>

These catalogs could be as simple or as complex as necessary, and catalogs could be added or removed at any time without recompiling the application. Additionally, using the XamlExtension MarkupExtension I blogged about previously, catalogs could easily be shared as follows:

<AggregateCatalog
    xmlns="clr-namespace:System.ComponentModel.Composition.Hosting;assembly=System.ComponentModel.Composition"
    xmlns:sys="clr-namespace:System;assembly=mscorlib"
    xmlns:mefp="clr-namespace:System.ComponentModel.Composition.Primitives;assembly=System.ComponentModel.Composition"
    xmlns:xe="clr-namespace:XamlExtensions;assembly=XamlExtensions"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <x:Arguments>
    <x:Array Type="mefp:ComposablePartCatalog">

      <AssemblyCatalog x:Arguments="MyApplication.exe" />

      <xe:Xaml Source="CommonExtension1.catalog" />

    </x:Array>
  </x:Arguments>
</AggregateCatalog>

The code to load the xaml encoded catalogs is pretty straight forward:

public static class XamlCatalogServices
{
    public static ComposablePartCatalog LoadCatalog(string filePath)
    {
        var catalog = XamlServices.Load(filePath) as ComposablePartCatalog;
        if (catalog == null)
        {
            throw new InvalidOperationException(string.Format("{0} is not a ComposablePartCatalog", filePath));
        }
        return catalog;
    }

    public static IEnumerable<ComposablePartCatalog> LoadCatalogs(string directory = null, string searchPattern = null, SearchOption searchOption = SearchOption.TopDirectoryOnly)
    {
        if (string.IsNullOrEmpty(directory))
        {
            directory = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location);
        }

        if (string.IsNullOrEmpty(searchPattern))
        {
            searchPattern = string.Format("{0}*.catalog", Path.GetFileNameWithoutExtension(Assembly.GetEntryAssembly().Location));
        }

        return Directory.EnumerateFiles(directory, searchPattern, searchOption).Select(filePath => XamlCatalogServices.LoadCatalog(filePath));
    }
}

Discovering and executing the pseudo entry points

Since my goal includes implementing a small, generic bootstrapper that can be used as the basis for any MEF-based application, the concept of an entry point must be abstracted. The application executable, which hosts the bootstrapper, will of course have the real entry point, but the bootstrapper will discover and execute pseudo entry points on a per-application basis. The approach I take here is to simply have the bootstrapper query the container (after the catalogs have been initialized) for an IEntryPoint and invoke it. I defined IEntryPoint as follows:

public interface IEntryPoint
{
    void BeginExecution();
}

An application could implement its own custom IEntryPoint, but I’ve found a few generic implementations to be sufficient in most cases. The first I called PartActivatingEntryPoint, which gets startup components running. This entry point “activates” parts with the “AutoActivate” contract. Examples of such parts might be the main window of an application, background services that are not consumed by other components but provide important functionality (such an auto-save component), etc. I defined PartActivationEntryPoint as follows:

[Export(typeof(IEntryPoint))]
public class PartActivatingEntryPoint : IEntryPoint
{
    [ImportMany("AutoActivate")]
    private IEnumerable<Lazy<object>> autoActivateParts;

    public virtual void BeginExecution()
    {
        this.autoActivateParts.Select(part => part.Value).ToArray();
    }
}

A subclass of PartActivatingEntryPoint that I’ve found useful is one I called WpfApplicationEntryPoint. It instantiates a System.Windows.Application class and then activates startup parts within the context of the Dispatcher. I defined WpfApplicationEntryPoint as follows:

[Export(typeof(IEntryPoint))]
public class WpfApplicationEntryPoint : PartActivatingEntryPoint
{
    public override void BeginExecution()
    {
        var application = new Application();
        application.Startup += delegate { base.BeginExecution(); };
        application.Run();
    }
}

Putting the pieces together

I’ve described my approach to preparing the part catalog and discovering and executing the pseudo entry points, and provided sample code showing basic implementations. The only remaining part is to pull these pieces together into the actual bootstrapper. This is easily done as follows:

public static class MEFBootstrapper
{
    public static void Run()
    {
        // Discover the catalogs and create the container
        var container = new CompositionContainer(new AggregateCatalog(XamlCatalogServices.LoadCatalogs()));

        // Query the container for the entry point
        var entryPoint = container.GetExportedValueOrDefault<IEntryPoint>();
        if (entryPoint == null)
        {
            throw new InvalidOperationException("No entry point found. Add an IEntryPoint to the container.");
        }

        // Invoke the entry point
        entryPoint.BeginExecution();
    }
}

MEFBootStrapper.Run can be invoked from the real application entry point. For example:

internal static class Program
{
    [STAThread]
    private static void Main()
    {
        MEFBootstrapper.Run();
    }
}

In fact, the same executable containing the Main method shown above could be used as the starting point for any MEF-based application that uses the bootstrapper that I’ve defined here (ok, a recompile of this executable would be necessary for a console application).

I’ve found this simple approach to composing extensible applications from loosely coupled reusable parts to be very successful. I hope others find it useful as well. I’ve made some sample code available as a simplified but complete demonstration of this approach. In the sample code, I deliberately made some parts “auto activated” while others are not since this is what I would expect in a real application. Feedback is welcome.

<Window.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="MyResources.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Window.Resources> 

Xaml is not really helping us with the reference to the shared resources in this example. Rather, ResourceDictionary has the logic to initialize itself from a Uri pointing to another ResourceDictionary. ResourceDictionary is certainly not the only data type you can imagine wanting to share and reference from multiple xaml documents. This is especially true with the .NET 4.0 release, where xaml has been completely decoupled from WPF and is much more suitable as a general purpose serialization/deserialization technology.

One simple approach to sharing and referencing xaml documents from other xaml documents is to implement a custom MarkupExtension. With a custom MarkupExtension, our xaml might look something like this:

<Window.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <Xaml Source="MyResources.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Window.Resources>

This looks almost exactly the same as the first ResourceDictionary example. The major difference is that it relies on a general Xaml MarkupExtension that will load any xaml document. This will work with ResourceDictionaries or any other data type in any xaml context (including WPF). Through the IServiceProvider exposed to MarkupExtensions, the necessary context is available to resolve relative Uris to absolute Uris, which are required for finding and deserializing the referenced xaml documents. A basic version of the Xaml MarkupExtension would look like this:

public class XamlExtension : MarkupExtension
{
    public Uri Source { get; set; }

    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        if (this.Source == null)
        {
            throw new ArgumentNullException("Source");
        }

        var absoluteUri = this.Source;
 
        if (!absoluteUri.IsAbsoluteUri)
        {
            var uriContext = (IUriContext)serviceProvider.GetService(typeof(IUriContext));
            if (uriContext != null && uriContext.BaseUri != null)
            {
                absoluteUri = new Uri(uriContext.BaseUri, absoluteUri);
            }
        }

        return XamlServices.Load(absoluteUri.AbsoluteUri);
    }
} 

The first thing to note about this is the method of resolving relative Uris. The IServiceProvider is queried for an IUriContext, which in turn provides the base Uri. The base Uri will be set appropriately as long as the original xaml document was loaded in such a way that the xaml deserializer can know where it came from. For example, if the xaml document was loaded from a physical file on disk, the xaml deserializer will know the base Uri. On the other hand, if the xaml document was loaded from a stream, the xaml deserializer will have no way of knowing a base Uri for the document being loaded. The second thing to note is that the referenced xaml document is loaded using XamlServices.Load and passing in the absolute Uri as a string. Although the documentation is a bit unclear on XamlServices.Load, the overload that takes a string can in fact be a Uri string. The third thing to note is the method of loading referenced xaml documents. Since an absolute Uri is used, and since the IUriContext is correctly configured when loading from a Uri using XamlServices.Load, multiple layers of references are possible, and references are always relative to the xaml document that contains the reference. In other words, it is valid to have a xaml document that references a xaml document that references a xaml document, etc, even when the xaml documents are located at different Uris (such as in different file system directories).

The last thing to note about this MarkupExtension is its use in the context of pack Uris, which are used extensively in WPF applications. Specifically, the "pack" prefix and web request factory are registered relatively early in the startup of a WPF application, but may not have been registered at the point where the MarkupExtension is invoked during deserialization. When this is the case, the "pack" prefix can be registered manually: 

System.Net.WebRequest.RegisterPrefix("pack", new System.IO.Packaging.PackWebRequestFactory()); 
 

As always, feedback is welcome.

The general idea is to use XNA's Texture2D class to load the DDS, then do a per pixel conversion to a WPF BitmapSource. First, I'll implement the core method for doing the conversion from a Stream to an ImageSource:

There are a few things worth noting here. First, note that only mip level one is being used as it is the highest resolution; the other mip levels are ignored. Second, note that alpha is being ignored entirely. There may be scenarios where this is important, but in many cases RGB data alone is sufficient and often desired. If alpha data is necessary, adding it should be a relatively minimal change.

Since the method above is intended for WPF applications, the DDS will likely be bound to a property of a WPF class, such as Image.Source. The DDS source may be a file path (e.g. loading from disk), may be a stream (e.g. loading from game content pack), may be a byte array (e.g. embedded resource), etc. This is another area where a WIC codec would provide a cleaner solution. The WPF ImageSource class already has a TypeConverter that handles converting from strings, streams, URIs, byte arrays, etc. by decoding the image using WIC. Since the XNA-based implementation provided here does not go through WIC, the binding must explicitly specify a converter. To support this, a custom IValueConverter can be used:

Following is a simple usage example:

My experience with XNA is limited (the XNA parts of the implementation above was achieved with the help of a former coworker), so it is entirely possible that the code provided could be improved. Again, the solution provided here is a quick, simple way to get DDS images displayed in WPF writing only managed code. As previously mentioned, implementing a DDS WIC codec would almost certainly be a more robust, long term solution, though also likely a heavier solution. I have no experience implementing WIC codecs, so if anyone wants to chime in on this I'd love to hear about it.

1. Data is loaded from some data source
2. A TextBox is bound to that data
3. The Text of the TextBox is changed
4. A ToolBar Button, MenuItem, or shortcut key is invoked to submit the data back to the data source
5. The data source remains unchanged!

Typically a ToolBar or a Menu has its own logical focus scope, and therefore interacting with them does not remove logical focus from the TextBox. If a shortcut key is pressed, this also typically will not remove logical focus from the TextBox. Since logical focus was not lost, the binding source was not updated, and so the seemingly changed data was not submitted back to the data source.

One simple solution is to exhaustively update all binding sources before submitting the data. This can be a bit tricky, so I'll walk through the code required for this.

First, I'll implement a couple DependencyObject extension methods that make traversing the visual tree simpler:

public static IEnumerable<DependencyObject> EnumerateVisualChildren(this DependencyObject dependencyObject)
{
    for (int i = 0; i < VisualTreeHelper.GetChildrenCount(dependencyObject); i++)
    {
        yield return VisualTreeHelper.GetChild(dependencyObject, i);
    }
}

public static IEnumerable<DependencyObject> EnumerateVisualDescendents(this DependencyObject dependencyObject)
{
    yield return dependencyObject;

    foreach (DependencyObject child in dependencyObject.EnumerateVisualChildren())
    {
        foreach (DependencyObject descendent in child.EnumerateVisualDescendents())
        {
            yield return descendent;
        }
    }
}

Next, I'll implement a DependencyObject extension method that updates the binding sources for all DependencyPropertys on that DependencyObject and all of its visual descendents:

public static void UpdateBindingSources(this DependencyObject dependencyObject)
{
    foreach (DependencyObject element in dependencyObject.EnumerateVisualDescendents())
    {
        LocalValueEnumerator localValueEnumerator = element.GetLocalValueEnumerator();
        while (localValueEnumerator.MoveNext())
        {
            BindingExpressionBase bindingExpression = BindingOperations.GetBindingExpressionBase(element, localValueEnumerator.Current.Property);
            if (bindingExpression != null)
            {
                bindingExpression.UpdateSource();
            }
        }
    }
}

All that's needed at this point is to invoke the UpdateBindingSources extension method on an appropriate DependencyObject (such as the top level Window) before submitting the data. This will ensure that the values in all binding targets have been pushed back to the binding sources. If the application in question has multiple Windows that should all have their binding sources updated, one more extension method may be useful:

public static void UpdateBindingSources(this Application application)
{
    foreach (Window window in application.Windows)
    {
        window.UpdateBindingSources();
    }
}

Optionally, this extension method could be called before submitting the data:

Application.Current.UpdateBindingSources();

It probably seems like this could be incredibly slow, but in practice, I've found that this causes no noticeable delay in a medium sized application with a significant number of bindings. If this became a performance bottleneck, it might be possible to optimize specifically around the case of UpdateTrigger.LostFocus by carefully examining the WPF FocusManager to determine the actual set of elements that currently have logical focus and only updating binding sources on those elements.

It's also worth noting that this generic solution can be incorrect in certain binding scenarios. For example, an application might be using Bindings with the UpdateSourceTrigger set to Explicit and use some special criteria to decide when to commit the binding changes. Obviously in such a case, an indiscriminant call to the UpdateBindingSources extension method might thwart those efforts. Again, in practice I've found this generic solution to solve the underlying problem without significant side effects.

If you have an alternative solution to this problem, I'd love to hear about it. Other feedback is of course welcome as well.