Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have a .net 4.0 project in which I’d like to reference .net 2.0 assemblies. As I understood from this article, .net 2.0 assemblies will be loaded in 4.0 run time and backward compatibility is not assured. Is there a way to force process side by side for this case and to load 2.0 runtime?
In process side-by-side versioning is only supported for code that runs independently without having to share data. In particular for native code that loads the CLR to execute managed code. It is a solution for the CLR versioning problem, once an unmanaged program like Explorer loads the CLR, say to support a shell extension written in .NET then the CLR version is selected by whatever version that extension asked for. Which works poorly if another extension then needs a later version of the CLR. .NET 4’s side-by-side versioning feature solves that, each extension gets its own CLR. No sharing of data is required, these extensions don’t know about each other.
Clearly this isn’t a solution for what you are trying to do. Microsoft made a lot of effort to make .NET 4.0 as compatible as possible with previous .NET releases and loading .NET 2.0 assemblies is certainly well supported. Up to a point, they did use the opportunity to fix several old bugs whose fixes could be breaking to old code. Technically it is possible that your 2.0 code relied on the behavior of such a bug, it is however not very likely. You just need to re-test your code.