A first hand look from the .NET engineering teams
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,
PingBack from http://blog.cwa.me.uk/2009/06/04/the-morning-brew-361/
Does this change the guidance for writing e.g. Shell extensions in managed code, which we are currently strongly discouraged to do? That includes writing a .NET 2.0 extension to a native application, starting today.
Assuming 1.0 and 1.1 extensions are extremely rare today (due to time, your guidance, and the brittleness of them), it looks like the "embargo" can be broken now and a world of opportunities open. Now, it would be really nice if all the interesting native hosts (Windows Explorer, IE etc) implemented official MEF shims and interop assemblies, so people could get going...
Software Development Tools TestDriven.Net 2.22: Support for Visual Studio 2010 Beta 1 Typemock Isolator 5.3.1 is Out! NDepend: Product Review Free Web Hosting to try ASP.NET 4 Beta1, VS2010 Beta 1, and MS Web Deployment Tool RC1 Microsoft Web Platform
That is correct - now that multiple CLRs can be hosted in one process at once, it is possible to write managed shell extensions. We will be writing a post exclusively covering this aspect very soon.
Will a host application be able to use In-Proc SxS without being rewritten to use the new hosting APIs?
What is the relantionship between MAF (Microsoft AddIn Framework) and In-Process Side by Side?
Rick Byers and I recently did a Channel9 talk on in-process SxS. If you'd like to know a bit more on the thinking and implementation behind this feature, please visit http://channel9.msdn.com/shows/Going+Deep/CLR-4-Side-by-Side-In-Process-What-How-Why/
MAF and in-process SxS are addressing isolation at different layers, and are meant to address different isolation requirements.
In-process SxS provides isolation at the unmanaged host level, and takes advantage of existing isolation boundaries like COM interop and custom unmanaged hosts.
On the other hand, MAF provides isolation that is directly integrated into the managed execution environment and provides isolation at a number of levels (domain/in-process/cross-process/cross-machine/etc), but requires client code to be written to its specific patterns.
Hope that helps.
The isolation of CLR v4.0 GAC is related to this new In-Process Side by Side feature? Also I'd like to know, if it is a good a idea to start developing shell extensions using .NET Framework 4.0. I'm asking this because the main reason for not doing that was the fact a process can load only one version of CLR at time.
Also, the MSDN Library documentation (http://msdn.microsoft.com/en-us/library/dd758089(v=VS.85).aspx) says
Shell extensions should not include managed code. Shell extensions are loaded into all processes that use the Shell namespace and run in-process by definition. Managed code built against one version of the common language runtime might not run in a process running a different version of the common language runtime. At this time, only one version of the common language runtime can be loaded into a process at one time. Therefore, Microsoft recommends against writing managed Shell extensions and does not consider them a supported scenario.
Maybe it is time to request a change on that documentation.
Let me know what you think,
I discovered that I can run .net 2.0 and 4.0 applications in the *same* app pool in IIS6, which previously was a no no. Is this due to the In-Process Side by Site feature? I can't find anything about this on the net, all msdn references say you can't run different versions in the same app pool, but it works.
I've written an open source library that provides base classes for Shell Extensions written in C#, but I'm intrigued to know whether the statement on MSDN at msdn.microsoft.com/.../dd758089 "Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario." is valid.
From what I can tell from the InProc SxS model, this is perfectly supported - one simply has to be careful with object lifecycles and managing resources, as is always the case with programming shell extensions - can anyone else shed any light on this?
We've got a VB.NET managed code application that is uses a very significant amount of complex J# code (in .NET assemblies), which was built & run on the .NET 2.0 CLR (now running on .NET 3.5). Our latest applications run on .NET 4.0, and we want to use the old code (and the J# code) in the same process. Running J# on .NET 4.0 is officially not supported - some users have reported a hack that you just programatically load the J# assemblies before calling any J# code - that works, but it crashes when we hit some java (not .NET) reflection code in our J# codebase : something some users may manage without.
"Side by side" execution sounds promising, but I'm struggling to work out if its useful in our scenario : Can we load & run J# assemblies on .NET 2.0 CLR ,while running the code that calls them on the .NET 4.0 CLR in the same process?.