Menu
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?
904
An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. Assemblies take the form of executable (.exe) or dynamic link library (. dll) files, and are the building blocks of . NET applications.
The term probing is often used when describing how the runtime locates assemblies; it refers to the set of heuristics used to locate the assembly based on its name and culture. You can view binding information in the log file using the Assembly Binding Log Viewer (Fuslogvw.exe), which is included in the Windows SDK.
In the Microsoft . NET framework, an assembly is a partially compiled code library for use in deployment, versioning and security. There are two types: process assemblies (EXE) and library assemblies (DLL). A process assembly represents a process which will use classes defined in library assemblies. .
Compiling the source code using the language compiler generates the corresponding assembly containing the MSIL. The assembly can be either a .exe or a . dll depending on the entry point defined in the Application.
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.
195
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> If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
