Hi all,

Please bear with me, but I was wondering about what happens when older
assemblies call code from a newer assembly when different framework versions
become involved...

Take, for example, a case where an application assembly (ASM1) and some
3rd-party assembly library (ASM2) are two private assemblies (not in the
GAC): both at version 1.0, both compiled against .NET 1.0, and where ASM1
calls into ASM2 for some piece of functionality.

If at some point, the company providing ASM2 upgrades their functionality
and redistributes a 2.0 version built against .NET 1.1, I'm wondering what
would happen if ASM2 were replaced with the new version on the machine and a
binding redirect were given to ASM1 in order to allow it to call into the
newer version of ASM2. Assuming both .NET 1.0 and .NET 1.1 are on the
machine and remembering that these are private assemblies which are not in
the GAC:

1: Would ASM2 be loaded within the .NET 1.1 CLR or would it load against
..NET 1.0 (meaning it would break if it happened to call into 1.1
functionality)?

2: If it IS a problem, how do you get around that issue? Are you required
to upgrade ASM1 to .NET 1.1?

3: Do the answers to 1 and\or 2 change if ASM1 is actually a library
(rather than an application) being called by a .NET 1.0 application assembly
(ASM3) that you have no control over (ie. meaning you cannot influence the
".config" file for ASM3)?

4: Do the answers change if only one of the two frameworks is on the
machine (ie. 1.0 only or 1.1 only)?

Thanks in advance,
Bill

Bill,

>1: Would ASM2 be loaded within the .NET 1.1 CLR

No, you can only have one version loaded per process. And if ASM1 is
the executable starting the process and it was compiled against v1.0,
then that will be the CLR version loaded by default.


>or would it load against
>.NET 1.0 (meaning it would break if it happened to call into 1.1
>functionality)?

Yes.


>2: If it IS a problem, how do you get around that issue? Are you required
>to upgrade ASM1 to .NET 1.1?

Configure the application to load v1.1 of the runtime, assuming ASM1
runs fine with it.


>3: Do the answers to 1 and\or 2 change if ASM1 is actually a library
>(rather than an application) being called by a .NET 1.0 application assembly
>(ASM3) that you have no control over (ie. meaning you cannot influence the
>".config" file for ASM3)?

Well yes, then the answer to #2 will obviously not work.


>4: Do the answers change if only one of the two frameworks is on the
>machine (ie. 1.0 only or 1.1 only)?

If you only have v1.0 installed and ASM2 uses v1.1 functionality, it
will not work.

If you only have v1.1, that runtime version will be loaded and
hopefully everything works as expected.




Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

So, in short, there is no more interoperability between code written against
framework versions 2 years apart than there is between that code and
unmanaged code written 25 years ago ?

Absurd would be an understatement.

"Mattias Sjögren" wrote:


> >2: If it IS a problem, how do you get around that issue? Are you required
> >to upgrade ASM1 to .NET 1.1?
>
> Configure the application to load v1.1 of the runtime, assuming ASM1
> runs fine with it.
>
>
> >3: Do the answers to 1 and\or 2 change if ASM1 is actually a library
> >(rather than an application) being called by a .NET 1.0 application assembly
> >(ASM3) that you have no control over (ie. meaning you cannot influence the
> >".config" file for ASM3)?
>
> Well yes, then the answer to #2 will obviously not work.
>
>
> >4: Do the answers change if only one of the two frameworks is on the
> >machine (ie. 1.0 only or 1.1 only)?
>
> If you only have v1.0 installed and ASM2 uses v1.1 functionality, it
> will not work.
>
> If you only have v1.1, that runtime version will be loaded and
> hopefully everything works as expected.
>
> Mattias
>
> --
> Mattias Sjögren [MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.
>