One of the new features in CLR 4 is In-Process Side-by-side (Inproc SxS) – a feature that lets you use multiple versions of .NET in the same process. For applications that use add-ins (particularly COM add-ins), in-proc SxS lets us provide a level of compatibility never before possible. If you write applications that use an add-in model (for Office or other hosts), you’ll want to understand the details of in-proc SxS, so that you can make use of the new hosting APIs that provide this compatibility. If you are thinking about using .NET 4, but worried about the impact of installing .NET 4 on end user machines, then you’ll want at least a high level understanding of in-proc SxS – it’s the feature that makes installing a new version of .NET less impactful than ever before. Finally, even if none of the above apply to you, you still might find this interesting – it’s probably the most complex change to the CLR in .NET 4.
This is a multi-part series dedicated to in-proc side-by-side, how it works, and all it’s nitty-gritty details.
What is In-Process Side by Side?
In-process side by side (Inproc SxS) is the ability to run multiple versions of the CLR in a single process.
Consider the following example from years ago. John was in the IT group of a Fortune 500 company. Some of his users had a .NET 1.1 Excel add-in from a company called DevelopersRUs (not their real name). The add-in had been working well for John’s users for years. When .NET 2 released, John wrote a new Excel add-in, which included a pre-requisite for the .NET 2 Framework which was then installed on their machines, and deployed it to his users.
In most cases, Office and other applications that host managed code will use the most recent version of .NET installed on a machine. That way, the host application can run both new add-ins (like John’s) and old add-ins (like the one from DevelopersRUs – keep in mind that until now you can only have one CLR loaded in the process.) The old add-ins will usually work just fine with the new runtime. When John installed his .NET 2.0 managed application on the machine, Excel started to use .NET 2.0 for all add-ins, including the DevelopersRUs one, which used to run against .NET 1.1. Now, as it happened, the DevelopersRUs application was bug-ridden in all sorts of ways – it had race conditions, depended on the internal layout of runtime data structures, and many other very bad things – all of which caused it to break when it started to run on .NET 2.0. There was nothing wrong with .NET 2.0, and nothing wrong with John’s application – but installing .NET 2 on the machine caused that existing application to stop working!
You can imagine John’s users were pretty upset when this happened. John explained to them that his application was just fine, and that .NET 2 was just fine – it was a problem with this third party product. Some of them understood, but none of them were very happy.
In fact, John would have the same problem even if he hadn’t been writing an add-in for Excel – if he just wrote, say, a simple console application that pre-required .NET 2.0, he could cause the same problem, since installing his application would cause Office and other hosts to use the newest runtime!
Fortunately, when .NET 4 comes out, John won’t have this kind of problem, because of in-process side-by-side. With in-proc SxS, add-in hosts get to use the version of .NET that each add-in was built and tested with. Installing .NET 4 on a machine won’t cause add-ins or applications to start using it, by default. That means that .NET 4 will be one of our least impactful new versions ever, and John can safely take a dependency on it.
It’s helpful to remember that we haven’t had to deal with the full-blown version of this kind of problem for several years now. .NET 2.0, 3.0, and 3.5 were built with what we refer to as the “layercake” model – in which version 3.0 added functionality on top of version 2.0, and version 3.5 on top of 3.0, without changing much functionality underneath. Adding functionality is almost always non-impactful. However, .NET 4 is a major new release, and we’ve made all sorts of improvements under the covers. While we’ve worked very hard to keep .NET 4 as compatible as possible, 100% compatibility is impossible, so in-proc SxS is an important part of keeping compatibility as the new versions change to support evolutionary needs, though we would try our best to keep new versions highly compatible.
The main scenario schema is shown below. A host can activate more than one CLR in its process. Each instance can load and execute as many add-ins as needed.
This post provides an introduction to in-process side by side. Stay tuned for the rest of the posts on this topic. If you have any questions on this functionality, please leave a note in the comments section of this post.
Luiz Fernando Santos,