Side by Side In Process CLRs Start with Silverlight
When we started working on managed code for Silverlight one scenario I wanted to see working was the ability to create a new browser or shell in managed code that could still browse to and execute rich web content. We spent (endless) time debating if this scenario should simply target the desktop CLR if it were installed and just use one CLR. In the end my main concern about that solution was ensuring 100% behavior compatibility. We strive really hard to reach this on the desktop already, and at some point just being able to execute what you wrote against is the best solution. So instead we went down the road of creating a separately factored CLR which could run side by side in the same process. To test this, I wrote a small managed application which hosted shdocvw.dll (IE’s core browser engine) and browsed to a Silverlight enabled web site. The first few times this was not a pretty experience <g>, but that was quickly fixed.
Enabling side by side CLRs in the same process not only enables this scenario, but it removes a long standing complaint from developers trying to write applications that implement add-in models for extensibility. In these cases, you often want to load and bind to the version of the CLR your add-in was built for. Previously one had to roll forward to the latest and greatest version to pull this off. It does work, but can be a little painful.
This video gives a demonstration of running two CLRs in the same process using a WPF demo I blogged about here:
There are a few things to notice in this diagram:
· There is no retroactive change to Versions 1.0, 1.1, or 2.0 of the CLR. Only one of these may be in the process at the same time. The diagram shows V2.0 (3.0 and “3.5” are built on top if used).
· Silverlight can run side by side with any one of the V1.0, V1.1, or V2.0 CLRs.
· Future versions of the CLR (which are under development already) will run side by side with the original desktop CLR instances and Silverlight.
Now that we have this feature, you may ask why it wasn’t there from the beginning. There were always two main considerations we had historically for not going down this road. The first is thread suspension. You need to ensure that if two CLRs are suspending threads to do a GC they don’t suspend each other in the process (there are some XML dlls out there today which do a poor job of this). The second consideration is the performance of the resulting process. Each CLR has its own GC heap and loaded code; they do not share data with each other (any interop between them must be done through unmanaged code / COM).
Given all of this, it is still our recommendation that if you are designing a new extensibility API for your application, try to make it work well with the add-in running out-of-process. This really does provide the cleanest way to isolate 3rd party code and keep the best possible compatibility. However if you are using an existing API extensibility model (sidebar, browser, etc) that was not designed for this, this new feature does simplify your life a lot.