Micah
Micah

Reputation: 116050

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 changes in the new version of workflow. It still using the old 3.5 version of WF.

Upvotes: 2

Views: 546

Answers (3)

John Gietzen
John Gietzen

Reputation: 49534

.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.

Upvotes: 4

louisgab
louisgab

Reputation: 2414

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

Upvotes: 0

stonemetal
stonemetal

Reputation: 6208

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

Upvotes: 0

Related Questions