If I have a 2.0 CLR assembly (pure managed code, no mixed mode issues) that I need to link to from a 4.0 CLR Application, does the 2.0 code run on the 2.0 CLR or 4.0.
Basically, is there any risk of 4.0 breaking changes affecting the 2.0 code?
views:
119answers:
3
+7
Q:
When linking a .NET 2.0 Managed Assembly from a .NET 4.0 Application, which framework is used?
+3
A:
Basically, is there any risk of 4.0 breaking changes affecting the 2.0 code?
Nope. Starting with .NET 4, you don't have to worry about compatibility issues at all! Version 4 introduced a new feature called "In-Process Side-by-Side Execution", which essentially allows you to load multiple versions of the CLR into the same process.
In other words, since your main application is running on the 4.0 runtime, you can tell it to load the 2.0 runtime when you load the 2.0 CLR assembly. The 2.0 CLR assembly will use the 2.0 runtime, while your application will continue to use the 4.0 runtime.
How do you specify this? I believe you can just add a config file for your 2.0 CLR assembly (e.g. "My.dll.config" in the same directory as "My.dll"), but I haven't tried it with DLLs myself. Nevertheless, here's what you put in your assembly's config file:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
htw
2010-10-03 22:03:47
This is correct, according to the docs. However, it appears that sometimes the C# compiler will add and alias v2.0 assemblies which then cause loading issues. Can you explain this? Here's an example: http://stackoverflow.com/questions/3841911/linking-to-a-net-v2-0-assembly-from-a-net-v4-0-assembly-also-appears-to-link-a
codekaizen
2010-10-06 01:45:31
Thanks for the answer, but I gave this a go by creating a quick test project. I have a console app running 4.0, and a class library running 3.5. I have created a config file as specified, and Environment.Version is 4.0 for both.
AlexWilson
2010-10-06 13:55:03
The config file won't work for a DLL. It needs to be added to the .EXE config file, since that is what is loaded by the runtime.
codekaizen
2010-10-07 18:38:24
But this would mean that the whole app can only run under one CLR version, which means that the 2.0 code would be exposed to any breaking changes, or am I missing something?
AlexWilson
2010-10-08 09:28:07
A:
if the answer from htw did not answer it for you, or it crashes on you. Have a look at this
dbones
2010-10-04 22:57:07
+3
A:
The answer above is incorrect. You do get side by side with the full frameworks. A .Net 2 APPLICATION (note that means EXE, not library) will not auto promote to .Net 4.
But if a .Net 4 application loads a .Net 2 assembly it is loaded into the same runtime (otherwise how could they share information). The .Net 2 assembly is loaded into the .net 4 runtime using a compatibility mode that is supposed to minimize breakage in changes (mostly for security changes in .Net 4).
A .Net 2 assembly cannot reference a .Net 4 assembly because it would not have features.
The ONLY exception to this that I know of is if you load a .Net assembly from a C++ app. The C++ application can load and host two runtimes. It could have a .Net 2 assembly and a .Net 4 assembly loaded, but they would not be able to talk to each other directly. This is how CLR Procs work in SQL Server. You can have a .Net 2 CLR Proc and a .Net 4 CLR Proc that do not communicate, but are both loaded on the server.
There was a great article on MSDN Magazine about hosting the .Net framework recently, but I can't find it now. Maybe someone else can post the link.
So you should be able to load just about any .Net 2 assembly into a .Net 4 executable without much problem. The only problems I have seen are with security permissions.
Jason Short
2010-10-08 01:20:01