Referencing DLLs in different version.

[=?Utf-8?B?a3lvbmc=?=]

Quick question.

Say I have a project against the 2.0framework. I also have a dll compiled
against 3.5. If I reference the 3.5 dll in the 2.0 project, how would that
work?

So I'm thinking that the 3.5 dll gets loaded in memory by the 3.5 framework
running in process X.

The 2.0 project dlls get loaded in the process running the 2.0 framework in
process Y.

So I would think that any calls will suffer out-of-process performance, but
at least it works. Am I correct on this? Would someone be able to help me
understand the situation here? Perhaps .net is doing something interesting
and the performance isn't really an issue between framework versions? Not
sure.

Thank you.

[Marc Gravell]

All of .NET 2.0, .NET 3.0 and .NET 3.5 run on CLR v2 (give or take a
service pack). It is the CLR version that would force issues; .NET 3.0
and .NET 3.5 are simply some extra dlls that run in the same CLR.

So in short, there is no issue here. You are simply referencing some
additional dlls. Blame marketing ;-p

Marc

[=?Utf-8?B?a3lvbmc=?=]

Thanks Marc for the reply.

I understand that the CLR version is the same for the three. However, it was
my understanding that the different frameworks needed to be loaded separately
(different processes) to accommodate for the different versions of the dlls
(there several dlls that were updated from the new versions).

Are you stating that all 2.0/3.0/3.5 frameworks all load under the same
process? Then how does it load different assembly versions? I suppose if it
loads different appdomains for each it should work, but I don't know at the
level of detail.

In any case, what you say doesn't quite make sense to me and I would love to
hear the explanation. From what I know, it should be that each 3.5 dlls will
be referencing their respective 3.5 dlls (if there are newer versions) and
they should all load in one process but maybe I'm missing something here.

I appreciate the time you took to respond! Thank you!

"Marc Gravell" wrote:

All of .NET 2.0, .NET 3.0 and .NET 3.5 run on CLR v2 (give or take a
service pack). It is the CLR version that would force issues; .NET 3.0
and .NET 3.5 are simply some extra dlls that run in the same CLR.

So in short, there is no issue here. You are simply referencing some
additional dlls. Blame marketing ;-p

Marc

[Marc Gravell]

Are you stating that all 2.0/3.0/3.5 frameworks all load under the same

process? Then how does it load different assembly versions?
I suppose if it loads different appdomains for each it should work [snip]

It doesn't. It comes down to "red bits", "green bits" and "blue
bits" ;-p [tongue in cheek...]

..NET 3.0 and 3.5 are *just* some extra assemblies. They managed to
get .NET 3.0 and 3.5 without introducing any extra IL instructions
[just lots of compiler tricks]. Which is why you can use C# 3 code
on .NET 2.0; once compiled, C# 3 code is just CLR2 IL.
The 3.5 installer /happens/ to install a service pack for 2.0 and 3.0,
but once that is done you *always* get that service pack - i.e. once
you've installed 3.5, even your "pure 2.0" code uses the 2.0 service
pack. So all you really have is an application that happens to
reference some things *called* 3.0 and 3.5 - but that is *just* their
name. Fundamentally they are CLR2, and that is what matters [give or
take a service-pack ;-p].

From what I know, it should be that each 3.5 dlls will
be referencing their respective 3.5 dlls

No; you're thinking CLR versions... if it was CLR 3.5, then yes, it
would be tricky. Again, key point: at the runtime level, there is
nothing special about .NET 3.0 or .3.5; this is *only* a marketing
term.

Marc