In Christian’s post Visual Authoring for the Windows 8 Consumer Preview he mentions that one of the changes to Blend is the introduction of an architecture that isolates the designer into its own process. In fact, this new architecture is used in both Blend and the XAML designer in Visual Studio. In this post, I’ll give a little more detail into what this means to you as a Metro style app author.

Stay on your side!

This new architecture isolates the runtime components from the products’ infrastructure and user interface into two processes.  The runtime components, which may also include user code, as well as most of the Blend user interface for XAML projects, such as the Properties panel, are hosted in the designer process (XDesProc.exe) while the project system and the code/XAML editors live in the host process (blend.exe for Blend and devenv.exe for Visual Studio).

This architecture enables Blend and Visual Studio to provide a full-fidelity, WYSIWYG design surface for Metro style apps across VB, C# and C++. We use the runtime implementation of WinRT to build our design-time experience. Specifically, we create a design-time AppContainer package and manifest that is separate from the runtime version. While the manifest and package are design-time specific, the user code in the package is identical to the runtime code.  However, this means that anything running in this process must follow the same security model as required for an AppContainer. Since Blend and Visual Studio need full access to the file system, these parts of the product’s infrastructure and user interface remain in blend.exe and devenv.exe.

When good processes go bad

Running user code on the design surface is great because it enables a degree of fidelity that would otherwise be impossible to achieve.  However, errors in the user code can also affect the designer process in Blend and Visual Studio. For C# and VB projects exceptions can frequently be caught safely, however for C++ projects there are many cases where user code can cause an exception that is impossible for the designer process to catch. The good news is that an exception in the designer process will typically not affect blend.exe or devenv.exe. When a serious problem happens in the designer process, you will see something like the following on the design surface:

If user code is causing the exception, once you correct the issue and rebuild, you can click the link to reload the designer.

User code is not the only reason for the message shown above to appear. Bugs in our own product code and the communication between the two processes can also cause designer exceptions.  A good rule of thumb is that if a reload fixes things, it is likely a bug in the product.  Of course we expect to have stabilized the product for the final release but it would also be appreciated if you would tell us about the bug by entering it at http://connect.microsoft.com/blend so we don’t miss any important scenarios.

If a reload does not fix things, it is possible that your code is expecting to access some part of WinRT that is not available at design time (e.g. ICoreWindow). If that seems likely, try using the DesignMode.DesignModeEnabled property to bypass this section of your code at design time.

When the pressure becomes too great

There is a very important benefit of the new architecture for Blend with respect to memory utilization. In general, when a project includes custom components, the user assemblies are regenerated on build, if they have changed since the last build. With the Blend 4 architecture, the newly built assemblies would be loaded but the out of date, or stale, assemblies would stay in memory.

The Blend 4 architecture did not take advantage of either app domains or a separate process, there was no way to unload the previous versions in .NET and these stale assemblies would effectively accumulate, taking up more and more memory with each build. This could cause Blend to eventually run out of virtual address space, especially if the component assemblies in the project contained large resources such as images.

With the new isolated designer architecture, we have the flexibility to restart the designer process if the memory pressure becomes an issue, causing the stale assemblies to be discarded. These restarts are done in the background, without interrupting your workflow.

Performance, performance, performance

There are also cases where the runtime requires that we restart the designer. For example, we must restart the process for each build with C++ projects. This can cause some performance issues for rebuild scenarios in C++. If you have multiple projects open and make a change to a shared control, it may result in several designer processes restarting at the same time.

With the new architecture, there is often additional overhead to communicate between the two processes. The XAML representation lives in the host process and changes made to the XAML in the designer process, say in the Properties panel or the design surface, must then be synchronized across the process boundaries.  If you have noticed some areas where the performance is slower than previous versions, it might be related to scenarios similar to these. Rest assured, we are working tirelessly on optimizing the performance of many scenarios and you can expect to see this improving from where it currently is in the Visual Studio 11 Beta release.

Joanna Mason
Lead Program Manager
Blend