Backwards compatability between .Net 2.0/3.5 and 4.0

I have an app that I've upgraded from 3.5 to 4.0. But not all my 3rd party assemblies are built on .net 4.0. How is it that I'm still able to reference those assemblies without any problems? For instance, if another assembly references system.dll 2.0, and my upgraded project references system.dll 4.0 how does .net handle this?

Obviosly this wasn't a problem upgrading between 2.0 and 3.5 because they use the same BCL and CLR versions, but 4.0 uses a completely different BCL and CLR right?

Here's an example. I have an app built using WF (Windows Workflow) in v3.5. I've upgraded the app to v4.0, but I wasn't required to implement all the breaking 开发者_JAVA技巧changes in the new version of workflow. It still using the old 3.5 version of WF.

.NET 4.0 can reference .NET 2.0 assemblies, but the reverse is not true.

.NET 4.0 assemblies support everything that 2.0 had, but adds in things like optional parameters, dynamic types, and etc...

So, since 2.0 doesn't have anything that 4.0 doesn't, 4.0 can easily support 2.0.

BCL and CLR are different but not completely different. Basically they worked hard to not break backwards compatibility.

You could also force your 3rd party assemblies to run under 3.5, as described in this post.