{"id":1363,"date":"2010-06-23T14:41:06","date_gmt":"2010-06-23T14:41:06","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2010\/06\/23\/in-proc-sxs-and-migration-quick-start\/"},"modified":"2022-06-10T09:50:54","modified_gmt":"2022-06-10T16:50:54","slug":"in-proc-sxs-and-migration-quick-start","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/in-proc-sxs-and-migration-quick-start\/","title":{"rendered":"In-Proc SxS and Migration Quick Start"},"content":{"rendered":"
\n
<\/div>\n

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\u2019re just interested in how we handle pre-.NET 4 and .NET 4 code coexisting on a machine.<\/p>\n

The problem<\/h2>\n

Prior 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.<\/p>\n

Our Solution<\/h2>\n

A new feature in the .NET 4 Runtime, \u201cin-process runtime side-by-side\u201d (or \u201cin-proc SxS\u201d for short) describes the ability to load more than one .NET Runtime version into the same process and have them run \u201cside by side\u201d. 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<\/span> to be loaded within their targeted runtime.<\/p>\n

Our Solution Is Not\u2026<\/i><\/h2>\n

In-proc SxS does not affect managed assembly loading, such as Assembly.Load<\/span> or loads due to assembly references \u2013 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<\/span> layer such as COM interop<\/span> and P\/Invoke.<\/p>\n

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<\/span> layers.<\/p>\n

How to Think About In-Proc SxS<\/h2>\n

Thinking about multiple runtimes in the same process without additional context isn\u2019t all that helpful; in fact, it just leads to more questions: \u201cHow and when does this happen?\u201d;<\/span> and most importantly, \u201cDoes this affect me?\u201d<\/p>\n

Does In-Proc SxS Affect Me?<\/h2>\n

In-proc SxS was designed so that existing applications, components and libraries should be completely unaffected by an installation of the .NET 4 Framework – applications that were running against a pre-v4 framework will remain blissfully unaware of the install.<\/p>\n

In addition, migrating<\/span> a product to .NET 4 is unlikely to be affected by in-proc SxS if:<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>The product is a pure managed application;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>The product is a pure managed library; or<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>The product is a pure managed COM component.<\/p>\n

However, a product may be affected by in-proc SxS during migration if:<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>The product makes use of one or more deprecated APIs; or<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>The product contains, or takes a dependency on, a mixed mode assembly<\/a> built with Visual Studio Managed Extensions for C++ version 8 or 9.<\/p>\n

 <\/p>\n

See the migration section below for more information.<\/p>\n

Runtime Activation<\/h2>\n

For the small number of you who may<\/i> be affected by in-proc SxS and need to gain a better understanding of it, the easiest way to understand how and where in-proc SxS fits into the managed world is to think about it as a fundamental change to our runtime activation model<\/em><\/span>. Runtime activation<\/i><\/b> describes the process by which the most appropriate runtime version is found, located, and loaded. A runtime request consists of a set of inputs, which can include (among others) an assembly (often the application\u2019s EXE), an application configuration file<\/a> (often found next to the application\u2019s EXE), a version string, or any combination thereof, and runtime activation uses these inputs to determine the most suitable match from among the set of installed runtimes. Common examples are: managed EXE launch, CoCreateInstanceInstance<\/span><\/a> of COM-visible managed types, and mixed-mode assemblies<\/a> loaded from native code.<\/p>\n

Old Activation Model<\/h3>\n

In prior releases, when in-proc SxS did not exist, our runtime activation policy had to take into consideration the reality that only one runtime could ever be loaded into a process. For self-contained managed applications the obvious choice was invariably the right one: activate the runtime that the application targets (derived either from metadata in the managed executable itself or from an application configuration file if one exists). And since virtually all managed application installers out there list the application\u2019s target runtime as a pre-requisite, the application could count on the target runtime being installed. Unfortunately, runtime activation was not always as clear cut in other important scenarios, the most prevalent of which is the activation of managed COM components. In such scenarios, the chosen policy has always been to activate in the latest installed runtime when no runtime has yet been loaded \u2013 a policy we call \u201cbind to latest.\u201d<\/p>\n

\n

Consider the following example to help understand why this policy was chosen for managed COM class activation. Let\u2019s say that a native application X exposes an extensibility mechanism through COM, and two authors separately write managed extensions A and B that target .NET Frameworks v1.1 and v2.0 respectively, and that application X and both extensions are installed on machine Z with both .NET Frameworks v1.1 and v2.0 installed.<\/p>\n

Say that, in the course of normal execution, application X CoCreateInstances<\/span> component A. In this case it may be tempting to use the same activation policy as that of managed executables<\/span> and pick the runtime that the component targets (v1.1). However, this choice would cause a later attempt to CoCreateInstance<\/span> component B to fail, because the .NET Runtime v1.1 (to which the process has been locked) cannot load a v2.0 assembly.<\/p>\n

To avoid this problem, the policy for managed COM component activation has always been to activate and load the component into the latest installed runtime, if a runtime has not yet been loaded. However, this policy created an impossibly high compatibility burden: we would need to provide 100% release-to-release compatibility, and to do so we would need to test every possible usage scenario for every managed application ever built on any previous .NET Runtime! So, while the entire .NET team will always set very high release-to-release compatibility requirements, we can all sleep a bit easier knowing that in-process side-by-side enables us to provide a much better compatibility model for our customers, insulating them from the small but inevitable accidental breaking changes that occur in a major product release.<\/p>\n<\/div>\n

New Activation Model<\/h3>\n

I\u2019m sure you\u2019ve guessed the fundamental change to our activation policy by now: starting with version 4, the .NET Runtime<\/span> activation policy may now load the most appropriate runtime version for a given activation request, without regard for the set of runtime version(s) that may already be loaded into the process<\/span><\/em>. The activation policy will no longer target the latest runtime on the machine as it did in previous versions (more details on this below). Again, there are some restrictions with when dealing with pre-v4 runtimes, but the above statement will hold true, without restriction, for all .NET Runtimes version 4 and higher.<\/p>\n

\n

Using the previous example, but with the small change that component A has been updated to target .NET 4, runtime activation policy is now free to activate component A in the v4 runtime and later activate component B in the v2 runtime. This provides the greatest compatibility by allowing components to run within their target runtime, without regard for the process environment into which it is loaded.<\/p>\n<\/div>\n

Now that we\u2019ve covered the basics of the new in-proc SxS feature and activation model, let\u2019s look at the necessary considerations when migrating<\/span> an application, component or library to .NET 4 from an earlier runtime.<\/p>\n

Migration<\/h2>\n
\n

In the vast majority of cases it is simple to migrate an application to run on .NET Framework 4: if you are migrating an application at the source level, import your solution into Visual Studio 2010 and choose \u201c.NET Framework 4\u201d for the Target Framework in each project\u2019s properties page, then recompile; if you are migrating an application without recompiling, create or update the application configuration file to target .NET 4.For example, the following is the recommended <startup> section to use when migrating an application that targets .NET 3.5 to also target .NET 4:<\/p>\n

<?xml<\/span> version =”1.0″?><\/p>\n

<configuration<\/span>><\/p>\n

<startup<\/span>><\/p>\n

<supportedRuntime<\/span> version=”v4.0″\/><\/p>\n

<supportedRuntime<\/span><\/span> version=”v2.0.50727″\/><\/p>\n

<\/startup><\/p>\n

<\/configuration><\/p>\n

Note that starting with .NET Framework 4, only a two-part version string is required, though three-part version strings are still accepted.<\/p>\n<\/div>\n

A migration decision tree is provided later in this section.<\/p>\n

Limitations and Exceptions<\/h2>\n

When transitioning code originally targeting an in-proc-SxS-unaware runtime to an in-proc-SxS-aware runtime, some additional steps will need to be taken if your application contains one or more of the following:<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>calls to any of the hosting global static functions<\/a>, from native and\/or managed code;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>calls to any of the Strong Naming Global Static Functions<\/a>, from native and\/or managed code;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>native code that calls CoCreateInstance<\/span> using any of the hosting CoClasses<\/span><\/a> (CLSID_CorRuntimeHost<\/span>, CLSID_CLRRuntimeHost<\/span>, CLSID_TypeNameFactory<\/span>, or ComCallUnmarshal<\/span>), or is managed code that uses COM interop<\/span> to access interfaces implemented by any of the same CLSIDs;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>calls to CoCreateInstance<\/span>, from native code, using any of the metadata CoClasses<\/span> (CLSID_CorMetaDataDispenser<\/span>, or CLSID_CorMetaDataDispenserRuntime<\/span>), or managed code that uses COM interop<\/span> to access interfaces implemented by any of the same CLSIDs;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>calls to CoCreateInstance<\/span>, from native code, using the CoClass<\/span> of any COM-registered .NET Framework type;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>a managed COM component (in the binary migration case only);<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>an<\/span> assembly produced with the Visual Studio Managed Extensions for C++ compiler (otherwise known as a managed C++ assembly<\/a>), or a dependency, either direct or indirect, on such an assembly.<\/p>\n

<\/a>Figure 1<\/p>\n

The functionality in the above list was created for prior releases, and each lacks the ability to specify the target framework that is needed for in-proc SxS, and could not be retrofitted to do so. For the most part, all of these chose the same \u201cbind to latest\u201d activation policy as managed COM component activation.<\/p>\n

Non-Impactful Install and \u201cLatest Runtime\u201d Activation Model<\/h3>\n

Why am I even talking about our \u201cbind to latest\u201d activation policy? Well, there\u2019s a very good reason: one of the primary compatibility-related goals of the .NET 4 Framework is to ensure that its installation is non-impactful to pre-existing managed application or component. To achieve this, we have had to modify the \u201cbind to latest\u201d activation policy\u2019s semantics in the .NET 4 release<\/span>.<\/p>\n

\n

The \u201cbind to latest\u201d runtime activation model kicks in when no target runtime version information is provided with the activation request, such as through a managed assembly\u2019s built-in version, a configuration file\u2019s list of <supportedRuntime<\/span>> entries, and\/or an explicit version string passed into any of the native hosting APIs that accept them. In these cases, in previous versions of the runtime, \u201cbind to latest\u201d activation would pick the very latest .NET Runtime installed on the machine. This is also the activation model used for managed COM classes built against pre-v4 runtimes, for precisely the reasons stated in the earlier example.<\/p>\n<\/div>\n

Starting with the .NET 4 Runtime, this \u201cbind to latest\u201d activation policy has been modified so that, by default, it will only consider pre-v4 runtimes. By making this the default behavior, all pre-existing applications and components using this activation model will be unaffected by the installation of .NET 4.<\/p>\n

Source Migration<\/h3>\n

If you intend to retarget your application or component to .NET 4 and rebuild, and it uses any of the functionality listed above, then you need to migrate to the equivalent functionality provided in the new .NET 4 Framework Hosting interfaces<\/a>:<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>for calls to any of the hosting global static functions<\/a>, use the corresponding methods provided by the new ICLRMetaHost<\/span><\/a>, ICLRMetaHostPolicy<\/span><\/a> and ICLRRuntimeInfo<\/span><\/a> interfaces;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>for calls to any of the Strong Naming Global Static Functions<\/a>, use the corresponding methods provided by the new ICLRStrongName<\/span><\/a> interface;<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>for<\/span> instance creation of any of the hosting CoClasses<\/span><\/a>, metadata CoClasses<\/span>, or COM-visible Framework types, use ICLRRuntimeInfo<\/span>::GetInterface<\/span><\/a>.<\/p>\n

Figure 2<\/p>\n

Each ICLRRuntimeInfo<\/span><\/a> and ICLRStrongName<\/span><\/a> interface instance targets a specific runtime, and each method exposes functionality specific to, or provided by, that targeted runtime.<\/p>\n

Binary Migration<\/h3>\n

If the preferred option of source migration and re-compilation is not possible, and the application or component also depends on any of the functionalities listed above, an application configuration extension is available to make migration possible in many cases. Adding this extension to the application\u2019s configuration file will modify the \u201cbind to latest\u201d policy to cause it to bind to the same runtime as the application itself. The extension takes the form of an attribute named useLegacyV2RuntimeActivationPolicy, to be placed in the <startup> element of an application configuration file. The attribute\u2019s valid values are \u201ctrue\u201d and \u201cfalse\u201d, of which \u201cfalse\u201d is the default. When set to \u201ctrue\u201d, this attribute instructs \u201cbind to latest\u201d runtime activation policy to consider all <supportedRuntime<\/span>> entries in the application configuration file; when set to false, the policy considers only those <supportedRuntime<\/span>> entries with a major version number of 2 or less. When a configuration file does not contain any <supportedRuntime<\/span>> entries (or a deprecated <requiredRuntime<\/span>> entry), then the version number contained in the executable image, which represents the runtime version against which the executable was built, is treated as an implicit <supportedRuntime<\/span>> entry (roughly speaking).<\/p>\n

\n

Thus, if you were migrating<\/span> a .NET 3.5 application to .NET 4, your configuration file might look like this:<\/p>\n

<configuration<\/span>>\n<startup useLegacyV2RuntimeActivationPolicy=”true”>\n<supportedRuntime<\/span> version=”v4.0″\/>\n<\/startup>\n<\/configuration><\/p>\n<\/div>\n

Figure 3<\/p>\n

Managed COM Component<\/h4>\n

To accommodate managed COM component authors (who in most cases cannot modify application configuration files), a separate mechanism is available: a semicolon delimited list of supported runtimes may be added to the component\u2019s InprocServer32 registration. Specifically, add the string value \u201cSupportedRuntimeVersions<\/span>\u201d to \u201cHKCRCLSID<COM component clsid<\/span>>InprocServer32<COM component version>\u201d.<\/p>\n

It is important to note that if a managed COM component depends on any of the items in <\/span>Figure 1<\/ins><\/span><\/span><\/span>, then it must be migrated at the source level<\/span>. This is because the COM component would need functionality equivalent to the new useLegacyV2RuntimeActivationPolicy configuration extension to work, which is a process-wide policy decision that must be made by the application author rather than by extensibility components.<\/p>\n

If a managed COM component is activated through a reg<\/span>-free manifest (which cannot be extended to contain a SupportedRuntimes<\/span> entry), runtime activation will look for a configuration file next to the assembly containing the COM visible class. Note that a useLegacyV2RuntimeActivationPolicy entry will be ignored in this scenario.<\/p>\n

Assemblies Built with Managed Extensions for Visual C++ Compiler<\/h4>\n

There are two additional limitations with managed C++ assemblies<\/a>.<\/p>\n

First, any dependency on a mixed-mode assembly<\/a> built with a previous release of Visual C++ must be migrated using the useLegacyV2RuntimeActivationPolicy configuration file extension. This is because all such assemblies depend implicitly on the managed CRT, which in turn contains dependencies on functionality listed in Figure 1.This dependency has been removed in the upcoming release.<\/p>\n

Second, all mixed-mode<\/a> assemblies (including those built using this release of Visual C++) and all assemblies built with a previous release of Visual C++ may be loaded into at most one runtime per process, because they may contain process-global static image data that cannot be virtualized across runtimes, and\/or because they depend on a prior release of the managed CRT. This limitation is virtually identical in nature to the current limitation restricting these types of assemblies to no more than one application domain at once.<\/p>\n

Migration Decision Tree<\/h2>\n

Use the following decision tree to decide the correct migration path for your component in the most common scenarios.<\/p>\n

\n

\"decision_tree\"<\/a><\/p>\n

\n

Binary Migration Examples<\/h2>\n

<\/a>Application: Target v2 and v4<\/h2>\n

Create an application configuration file with the following contents, where the highlighted portion is required only if the application depends on functionality from Figure 1:<\/p>\n

<configuration<\/span>> <\/span> <\/code><\/p>\n

 <\/p>\n

<startup useLegacyV2RuntimeActivationPolicy=\"true\"<\/span>> <\/span> <\/code><\/p>\n

 <\/p>\n

<supportedRuntime<\/span> version=\"v4.0\"\/> <\/span> <\/code><\/p>\n

 <\/p>\n

<supportedRuntime<\/span><\/span> version=\"v2.0.50727\"\/> <\/span> <\/code><\/p>\n

 <\/p>\n

<\/startup> <\/span> <\/code><\/p>\n

 <\/p>\n

<\/configuration> <\/span> <\/code><\/p>\n

 <\/p>\n

<\/code><\/p>\n

 <\/p>\n

 <\/p>\n

As always, <\/code>supportedRuntime<\/span><\/code><\/span> entries are considered to be listed in decreasing preference; if the .NET 2 Runtime is preferred, the entries should be reversed. <\/b> <\/code><\/p>\n

 <\/p>\n

Application: Target v4 Only<\/span><\/h2>\n

Use the same application configuration file as above, but remove the v2-specific supportedRuntime<\/span><\/code><\/span> entry.<\/p>\n

Managed COM Component: Target v2 and v4<\/h2>\n

If you authored a managed COM component built against the .NET 2 Runtime, with a CLSID of {DFEEABC2-17FF-4ce6-B25B-A35F7A156C68}<\/span><\/code> and a version of 6.2.0.0<\/span><\/code>, and you wanted the component to run within either the .NET 2 Runtime or the .NET 4 Runtime (in that order of preference), the registry update (in RegEdit<\/span> syntax) would be:<\/p>\n

[HKCRCLSID{DFEEABC2-17FF-4ce6-B25B-A35F7A156C68}InprocServer326.2.0.0] <\/span> <\/code><\/p>\n

 <\/p>\n

\"SupportedRuntimeVersions<\/span>\"=\"v2.0.50727;v4.0<\/span>\"<\/span><\/code><\/p>\n

\n

 <\/p>\n

If your component was registered without the assembly version portion of the registry key name, you would remove \u201c6.2.0.0<\/span><\/code>\u201d from the key name.<\/p>\n

Or, if your managed COM component is activated through registry-free COM, you would place an application configuration file (should we coin the term component configuration file<\/i>?) next to the managed COM assembly with contents similar to the example above<\/a> (without the highlighted portion, and with the supportedRuntime<\/span><\/code><\/span> entries reversed).<\/p>\n

Troubleshooting<\/h2>\n

Instantiating Managed COM Components From<\/span> Managed Code<\/h2>\n

If your application instantiates and uses COM components through the .NET Runtime\u2019s managed interop<\/span> layer, and one of those COM components happens to be managed, then there is a small chance that after migrating your application you might run into an error similar to this:<\/p>\n

Error: Unable to cast COM object of type 'System.__ComObject<\/span>' to interface type 'X<\/i>'. This operation failed because the QueryInterface<\/span> call on the COM component for the interface with IID '{12345678-1234-1234-1234-123456789012<\/i>}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)). <\/b> <\/span><\/code><\/p>\n

 <\/p>\n

<\/b><\/code><\/p>\n

 <\/p>\n

 <\/p>\n

This error can occur as a result of the following two combined conditions:<\/p>\n

1.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/b><\/code>The managed COM component is registered against a different .NET Runtime version from that of the instantiating caller, causing it to be activated in another runtime than that of the instantiating caller.<\/code> <\/b><\/code><\/p>\n

 <\/p>\n

2.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/b><\/code>The interface is not marked with <\/code>System.Runtime.InteropServices.ComVisibleAttribute<\/span><\/code><\/span>, with a value of <\/code>true<\/span><\/code>.<\/code> <\/b><\/code><\/p>\n

 <\/p>\n

This scenario worked in the past because of a runtime optimization: when the .NET Runtime notices that a COM type it instantiates has a managed implementation, and that it was instantiated into the same Application Domain as the instantiating caller, it bypasses the managed interop<\/span> layer and returns to the caller the managed object itself. In prior .NET Framework releases (where in-proc SxS was not available), all managed COM types and their managed clients were commonly loaded into the same Application Domain, allowing the implementing managed object to be returned, and in turn allowing the interface cast succeed without being marked as ComVisible<\/span>. <\/b> <\/code><\/p>\n

 <\/p>\n

Migrating<\/code><\/span> an application can easily create condition 1; if the application also relies on condition 2 (which is much less common), then the above error will be encountered. There are a couple of solutions available: <\/b> <\/code><\/p>\n

 <\/p>\n

1.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/code>Get an updated version of the managed COM type that properly declares the interface as ComVisible<\/span>. <\/code><\/p>\n

 <\/p>\n

2.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Update the application configuration file to use the <\/code>useLegacyV2RuntimeActivationPolicy extension.<\/p>\n

Loading Managed C++ Assemblies Built Against Previous .NET Runtime Versions<\/h2>\n

Attempting to load a managed C++ assembly that was built with an earlier compiler into the .NET 4 Runtime when the application has not been configured with the useLegacyV2RuntimeActivationPolicy configuration file extension will result in the following error:<\/p>\n

System.IO.FileLoadException<\/span><\/code><\/span>: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information. <\/span> <\/code><\/p>\n

 <\/p>\n

Note: the error is not 100% correct, as it specifies that only mixed mode assemblies are subject to this problem; it should say \u201cManaged C++\u201d instead of \u201cMixed mode\u201d, as managed C++ assemblies compiled with \/clr:pure<\/span><\/span><\/code> will also encounter this error.<\/p>\n

It is possible to correct this issue with either of the following:<\/p>\n

1.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Recompile the assembly with the .NET 4 managed C++ compiler<\/span>.<\/p>\n

2.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Update the application to use the useLegacyV2RuntimeActivationPolicy configuration file extension.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":342,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[],"class_list":["post-1363","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet"],"acf":[],"blog_post_summary":"

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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1363","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/342"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=1363"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1363\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=1363"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=1363"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=1363"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}