In-Process Side by Side Part 2 - Common in-proc SxS scenarios

In-Process Side by Side Part 2 - Common in-proc SxS scenarios

  • Comments 6

Update: The information in this blog post applies to pre beta-1 behavior and is not applicable to beta 2 and RTM. We will have more posts and documentation on this subject as we get closer to RTM.

 

This section covers the most common in-process side by side scenarios. The scenarios cover which CLR is used to run the specific code, given a particular machine configuration. 

Native Application calling Managed COM Components

Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3.5 or v3.5) and CLR 4 installed

In this scenario, all Legacy Managed COM Components will execute against CLR 2.0 and any call to the Global Hosting APIs, in the whole process (in the application or any assembly activated through COM or legacy API), will return CLR 2.0 results.  Also, any activated Managed COM Components compiled against CLR 4 will execute against CLR 4, in-process side by side with others, compiled against CLR 2.0 (executed against CLR 2.0).

Native Application calling the legacy Global Hosting APIs

Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3.5 or v3.5)  and CLR 4 installed

In this scenario, any call to these functions, in the whole process (in the application or any assembly activated through COM or legacy API), will return CLR 2.0 results.

Managed Application compiled against v4 calling Managed COM components

Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3.5 or v3.5)  and CLR 4 installed

In this scenario, a managed application compiled against CLR 4 calls a managed COM component compiled against CLR v1.x, CLR v2.0 or CLR 4.  In this situation, any call to the Global Hosting APIs, in the whole process (in the application or any assembly activated through COM or legacy API), will return CLR 4 results.  Also, any activated legacy Managed COM Components will execute against CLR 4.

Managed Application compiled against v4 using P/Invokes to call the legacy Global Hosting APIs

Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3 or v3.5) and CLR 4 installed

In this scenario, a managed application compiled against v4 uses P/Invoke to call the existing legacy Global Hosting APIs.  In this situation, any call to these functions, in the whole process (in the application or any assembly activated through COM or legacy API), will return CLR 4 results.

Managed Application compiled against v2 calling Managed COM components compiled against CLR 4

Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3.0 or v3.5) and CLR 4 installed

In this scenario, a managed application compiled against CLR 2.0 calls a managed COM component compiled against CLR 4.  In this scenario, any activated Managed COM Components will execute against CLR 4 in-process side by side with CLR 2.0.

What are the most common non-default scenarios?

This section illustrates some common scenarios and the corresponding configuration file entries in order to get the right results.

Native Application rolling forward all its Managed COM Components to CLR 4

Machine Configuration:  CLR 4 installed (other CLRs can be installed also, but in this case, this is irrelevant)

In this scenario, a native application needs to activate all its managed COM components (independently of the CLR version they were compiled against) using CLR 4.  In this situation, an APP.CONFIG file needs to be included in the same directory of the native application (EXE) with the following entry:

<startup>

<process>

<rollForward enabled="true" />

</process>

</startup>

This configuration will force all Managed COM Components to execute against CLR 4.

Native Application using legacy Global Hosting APIs to return CLR 4 results

Machine Configuration:  .NET 4 installed (other CLRs can be installed also, but in this case, this is irrelevant)

In this scenario, a native application uses the existing Global Hosting APIs to return CLR 4 results.  To accomplish that, an APP.CONFIG file needs to be included in the same directory of the native application with the following entry:

<startup>

<process>

<rollForward enabled="true" />

</process>

</startup>

This configuration will force all Managed COM Components to execute against CLR 4.  It's important to note that some Global Hosting APIs may not be affected by the APP.CONFIG file above.

Managed Application compiled against v2 rolling forward to execute against CLR 4

Machine Configuration:  .NET 4 installed (other CLRs can be installed also, but in this case, this is irrelevant)

In this scenario, a managed application compiled against v2.0 needs to execute against CLR 4.  In this situation, an APP.CONFIG file needs to be included in the same directory of the managed application (EXE) with the following entry.

<startup>

<supportedRuntime version="v4.0.XXXX" />

</startup>

Where XXXXX is the CLR build number.  In this situation, any Managed COM Component activated by this application will also roll forward to CLR 4.  Also, any Global Hosting API call in the whole process (in the application or in any of the Managed COM components) will return CLR 4 results (for example, CorBindToRuntime(pwszVersion=NULL) or GetCORSystemDirectory).

Managed Application compiled against v4 turning on In-process Side By Side

Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3.0 or v3.5) and CLR 4 installed

In this scenario, a managed application compiled against CLR 4 needs to activate Managed COM Components compiled against CLR 4 side by side with Managed COM Components compiled against CLR 2.0 (or previous version).  In this situation, an APP.CONFIG file needs to be included in the same directory of the managed application (EXE) with the following entry.

<startup>

<process>

<rollForward enabled="false" />

</process>

</startup>

Managed Application compiled against v2 running against v4 and turning on In-process Side By Side

Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3.5 or v3.5) and CLR 4 installed

In this scenario, a managed application compiled against CLR 2.0 needs to run against CLR 4 and also needs to activate Managed COM Components compiled against CLR 4 side by side with Managed COM Components compiled against CLR 2.0 (or previous version).  In this situation, an APP.CONFIG file needs to be included in the same directory of the managed application (EXE) with the following entry.

<startup>

<supportedRuntime version="v4.0.XXXXX" />

<supportedRuntime version="v2.0.50727" />

<process>

<rollForward enabled="false" />

</process>

</startup>

 

 

 

Luiz Fernando Santos,

PM, CLR

Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post
  • how can I follow this on twitter...

  • Introducing such a topic you'd like to congratulate you've let us know. Have good work

  • Hi there, will InProc SxS also make it possible to develop managed extensions in .NET 4.0 for Microsoft server products that are built on .NET 2/3/3.5, e.g. SharePoint and BizTalk?

    E.g. writing a SharePoint 2010 custom WebPart in .NET 4. This would mean that:

    1) in a single process (IIS web application managed by SharePoint) both CLR 2 and 4 are loaded, and

    2)that the standard SharePoint .NET 3.5 based component loads and invokes a custom webpart assembly which targets the .NET 4.0 framework.

  • I found the answer to my question above at http://msdn.microsoft.com/en-us/library/ee518876(VS.100).aspx:

    "Library developers and consumers. Side-by-side hosting does not solve the compatibility problems that library developers face. A library that is directly loaded by an application -- either through a direct reference or an Assembly..::.Load call -- continues to use the runtime of the AppDomain it is loaded into. This means that if an application is recompiled to run using the .NET Framework 4 Beta 2 runtime, but has dependent assemblies that were built using the .NET Framework 2.0 SP1, those assemblies will use the .NET Framework 4 Beta 2 runtime as well. Therefore, you should test your libraries against all version of the .NET Framework that you wish to support."

    Which means 'no'.

  • This is very good news was well informed that the followers of the issue I am. Thank you

  • Dear Abhishek,

    Thanks for the post. A very informative post indeed.

    I have a query. In the following scenario, if the Managed COM compiled against CLR2 is internally loading a .NET dll compiled in CLR 2, in which CLR this internally loaded dll would run? CLR 2 or CLR 4?

    "Managed Application compiled against v4 turning on In-process Side By Side

    Machine Configuration:  Both CLR 2.0 (.NET v2.0, v3.0 or v3.5) and CLR 4 installed

    In this scenario, a managed application compiled against CLR 4 needs to activate Managed COM Components compiled against CLR 4 side by side with Managed COM Components compiled against CLR 2.0 (or previous version).  In this situation, an APP.CONFIG file needs to be included in the same directory of the managed application (EXE) with the following entry"

    Thanks a lot.

Page 1 of 1 (6 items)