This post is meant to help you understand what runtime in-process side-by-side is, how to think about it, how to use it, and how it affects application and component migration to the .NET 4 Runtime. This post is relevant to you if you use native runtime activation APIs, depend on specific runtime activation behaviors, or use mixed mode assemblies built with Visual Studio Managed Extensions for C++ v8 or v9, or if you’re just interested in how we handle pre-.NET 4 and .NET 4 code coexisting on a machine. The problemPrior to the .NET 4 Runtime, any given process was limited to loading only one runtime version, and was bound to that runtime for remainder of that process lifetime. In environments where independently authored components built and tested against different .NET Runtime versions can be loaded into a single process, this sometimes caused compatibility problems for the components that did not target the runtime that was loaded into the process. Our SolutionA new feature in the .NET 4 Runtime, “in-process runtime side-by-side” (or “in-proc SxS” for short) describes the ability to load more than one .NET Runtime version into the same process and have them run “side by side”. This ability to load multiple runtimes into the same process gives us with the ability to provide the highest level of compatibility possible for environments in which multiple independent managed components are loaded by, and communicate with, a native layer. COM is the biggest example of a native layer through which managed code must communicate, and this means that in an environment in which multiple independently-authored managed COM components are activated, each may be loaded into the runtime for which it was built and tested, which maximizes compatibility. The upcoming release of Visual Studio Tools for Office (VSTO) will take advantage of this by enabling all managed office addins to be loaded within their targeted runtime. Our Solution Is Not…In-proc SxS does not affect managed assembly loading, such as Assembly.Load or loads due to assembly references – these scenarios continue to load the target assembly in the runtime where the load request was made. To take advantage of in-proc SxS, a managed component must be activated by a native host and interact with its environment through a native interop layer such as COM interop and P/Invoke.
This may be easier to understand if you consider that that two runtimes loaded into a process operate completely independently; i.e., runtime X has no more knowledge about runtime Y than it does about any other native DLL loaded into a process. Each runtime has its own GC; each runtime creates, owns, and manages its own Application Domains (never the other way around), including Shared and Default domains for each; and each runtime interacts with unmanaged DLLs through interop layers. How to Think About In-Proc SxSThinking about multiple runtimes in the same process without additional context isn’t all that helpful; in fact, it just leads to more questions: “How and when does this happen?”; and most importantly, “Does this affect me?” Read more: CLR Team Blog
This may be easier to understand if you consider that that two runtimes loaded into a process operate completely independently; i.e., runtime X has no more knowledge about runtime Y than it does about any other native DLL loaded into a process. Each runtime has its own GC; each runtime creates, owns, and manages its own Application Domains (never the other way around), including Shared and Default domains for each; and each runtime interacts with unmanaged DLLs through interop layers. How to Think About In-Proc SxSThinking about multiple runtimes in the same process without additional context isn’t all that helpful; in fact, it just leads to more questions: “How and when does this happen?”; and most importantly, “Does this affect me?” Read more: CLR Team Blog
Posts
0 comments:
Post a Comment