In-Process Side by Side Part 2 – Common in-proc SxS scenarios
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
Light
Dark
0 comments