Running multiple WPF applications in the same process using AppDomains

Why?

There are various reasons you may want to run several full-blown independent WPF applications side-by-side in the same process. In my particular case this was a client project where we were building a composite WPF trading desk. One of the requirements was to be able to run different versions of the same component (montage, P&L, blotter, etc.) side-by-side but within seemingly integrated environment. The best solution turned out to be running different versions in completely independent environment (application) and only communicate across domains using a thin protocol to provide “integrated” look and feel. Running components in separate domains let us avoid all the problems that come with signing, versioning, evolving dependencies, and many more.

This post is a step by step guide to demonstrate the techniques involved.

Improving Performance of XML Serializers in .Net

Problem background

.Net infrastructure makes it very easy to define and use strongly typed wrappers (XML serializes) to read from and write to an XML document. Default implementation of this support comes with a performance penalty that your program pays at run-time. By default, at runtime, .Net infrastructure will generate a serializer class on the fly, compile it using C# compiler into a temporary assembly, load the assembly and then use the generated class. Startup time cost of doing so is obvious, and may not be acceptable in many scenarios. In addition if compiler is not available in production (not installed, or disabled to run by policy), application will simply fail. This article shows how to address the problem by explicitly generating serialization assemblies and shipping them along with your application.

Running WPF Application with Multiple UI Threads

Introduction

It’s a good, time-proven practice to perform long, CPU intensive tasks on some sort of a background thread to improve your UI thread responsiveness. Sometimes though UI-related tasks themselves can be quite expensive. WPF, for examples, forces you to do all UI work on the thread that created the UI. A very flexible WPF measure/layout paradigm for UI rendering also comes with high CPU usage cost. In a very UI intensive application (for example, trading app with about ten windows showing real-time montage and blotter data) simply the cost of generating and laying out visuals can become too high for a single thread to keep up. When your UI thread saturates individual windows may start skip rendering cycles, become slow to response to user input, or even freeze. If your UI thread approaches this kind of saturation you should consider creating dedicated UI threads for some (or all) of your UI-intensive windows. This post is a step by step walk-through of doing just that.

Composite WPF: Improving Out-of-the-Box Module Dependency Resolution

Introduction

Microsoft has recently released its long awaited composite application framework for WPF (http://www.codeplex.com/CompositeWPF). As a heavy user and a big fan of the original CAB/Smart Client framework I rushed to explore it. To say that I was impressed is to say nothing. The [patterns & practices] team has done a tremendous job. The first thing that amazed me is the quality of the supporting documentation: direct mentioning and in-depth discussion of patterns used and architectural  decisions made, extensive tutorials and walk-throughs on all major concepts, and very cool reference implementation. So I immersed myself in CompositeWPF implementation to figure out how it stands against its CAB predecessor. I was specifically interested to see what CAB’s deficiencies were addressed and what are the areas improved and polished. So I started from the very beginning…

At the core of the composite application framework lies dynamic discovery and dependency resolution of its modules. This article discusses dependency resolution implementation in the new framework, its limitations (in both new and original frameworks), and suggests the ways to overcome those limitations.