A question on 1.1 and 2.0 interoperability

Is it possible to call a dll that was compiled against 1.1 when the exe is
compiled against 2.0?
I have bought some dll's that are compiled against 1.1 and, obviously, I
don't have the source code. I hate to buy all libraries again each time
Microsoft moves its frzamework forward.
Roland

Jon
Sun Oct 22 06:42:39 CDT 2006

Roland <roland.demeester@skynet.be> wrote:
> Is it possible to call a dll that was compiled against 1.1 when the exe is
> compiled against 2.0?
> I have bought some dll's that are compiled against 1.1 and, obviously, I
> don't have the source code. I hate to buy all libraries again each time
> Microsoft moves its frzamework forward.

Yes, that should be fine. There are a few changes between 1.1 and 2.0
which aren't backward-compatible, and if the libraries rely on the
original behaviour then you may have problems, but those are pretty
rare.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Roland
Sun Oct 22 07:02:19 CDT 2006

Actually, I found a possible answer on my question by reading the post from
Carl Daniel on Oct 17.
He stated that only one version of the CLR can be hosted in a process.
If this is the case, there are major consequenses each time the framework
moves forward:

All libraries that you bought from third parties need to upgraded, in plain
english: you have to buy them again.
You wil be forced to move to the latest version of the framework when you
want to buy a library fom a third party, because it will be compiled against
the latest version of the CLR, and it will probably only run in that
environment.
All libraries that you have developed yourself need to be recompiled and
tested again. Probably you'll need to maintain several versions, unless you
make sure that they are behaving well when running in an earlier CLR.

At least there was some interoperability possible between the framework and
activeX, but now that we entered the world of managed code, we are again
facing the fact that (framework) dll's are not backward compatible (back to
the future of dll hell?)
Any comments?

"Roland" <roland.demeester@skynet.be> wrote in message
news:%23h9SU2c9GHA.3960@TK2MSFTNGP05.phx.gbl...
> Is it possible to call a dll that was compiled against 1.1 when the exe is
> compiled against 2.0?
> I have bought some dll's that are compiled against 1.1 and, obviously, I
> don't have the source code. I hate to buy all libraries again each time
> Microsoft moves its frzamework forward.
> Roland
>

Roland
Sun Oct 22 07:05:13 CDT 2006

John, you mean that in that case the dll is executing the code of the CLR
loaded by the exe?

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1fa5698c8c9a159a98d56b@msnews.microsoft.com...
> Roland <roland.demeester@skynet.be> wrote:
>> Is it possible to call a dll that was compiled against 1.1 when the exe
>> is
>> compiled against 2.0?
>> I have bought some dll's that are compiled against 1.1 and, obviously, I
>> don't have the source code. I hate to buy all libraries again each time
>> Microsoft moves its frzamework forward.
>
> Yes, that should be fine. There are a few changes between 1.1 and 2.0
> which aren't backward-compatible, and if the libraries rely on the
> original behaviour then you may have problems, but those are pretty
> rare.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too

guffa
Sun Oct 22 08:39:09 CDT 2006

Most DLLs developed using framework 1.1 should run just fine using
framework 2.0. Actually, as the JIT compiler has improved quite a bit,
they should actually run better using framework 2.0.

There are some classes and methods that are made obsolete but they are
not removed, so the 1.1 code can still use them although code compiled
for 2.0 has to use the new versions of the classes.

There is a list of breaking changes from framework 1.1 to 2.0 that you
can look up if you want. It's the changes that had to be done that makes
some methods incompatible between 1.1 and 2.0. They are not so many, and
it's unlikely that you will run into any of them.

Roland wrote:
> Actually, I found a possible answer on my question by reading the post from
> Carl Daniel on Oct 17.
> He stated that only one version of the CLR can be hosted in a process.
> If this is the case, there are major consequenses each time the framework
> moves forward:
>
> All libraries that you bought from third parties need to upgraded, in plain
> english: you have to buy them again.
> You wil be forced to move to the latest version of the framework when you
> want to buy a library fom a third party, because it will be compiled against
> the latest version of the CLR, and it will probably only run in that
> environment.
> All libraries that you have developed yourself need to be recompiled and
> tested again. Probably you'll need to maintain several versions, unless you
> make sure that they are behaving well when running in an earlier CLR.
>
> At least there was some interoperability possible between the framework and
> activeX, but now that we entered the world of managed code, we are again
> facing the fact that (framework) dll's are not backward compatible (back to
> the future of dll hell?)
> Any comments?
>
> "Roland" <roland.demeester@skynet.be> wrote in message
> news:%23h9SU2c9GHA.3960@TK2MSFTNGP05.phx.gbl...
>> Is it possible to call a dll that was compiled against 1.1 when the exe is
>> compiled against 2.0?
>> I have bought some dll's that are compiled against 1.1 and, obviously, I
>> don't have the source code. I hate to buy all libraries again each time
>> Microsoft moves its frzamework forward.
>> Roland

Carl
Sun Oct 22 08:56:11 CDT 2006

Roland wrote:
> Actually, I found a possible answer on my question by reading the
> post from Carl Daniel on Oct 17.
> He stated that only one version of the CLR can be hosted in a process.

That's true.

> If this is the case, there are major consequenses each time the
> framework moves forward:

That's not true.

Other than a few rare cases, libraries compiled for 1.1 will run on the 2.0
CLR without any problems. Likewise going forward to .NET 3.0 and beyond:
existing libraries will continue to work.

> All libraries that you bought from third parties need to upgraded, in
> plain english: you have to buy them again.

No, not so.

> You wil be forced to move to the latest version of the framework when
> you want to buy a library fom a third party, because it will be
> compiled against the latest version of the CLR, and it will probably
> only run in that environment.

That will be true to some extent, just as it is with Windows versions.
Today, most .NET component vendors ship 1.1 and 2.0 versions of their
components (unless the component requires some 2.0 feature, of course).
Eventually they'll drop the 1.1 support, but it's in their best interest to
give you a smooth transition.

> All libraries that you have developed yourself need to be recompiled
> and tested again. Probably you'll need to maintain several versions,
> unless you make sure that they are behaving well when running in an
> earlier CLR.

Need to be recompiled? No. You'll probably want to recompile them for the
new framework eventually, but it's not required. Retested? Sure, just like
you would re-test your code when it's run on a new version of Windows.

> At least there was some interoperability possible between the
> framework and activeX, but now that we entered the world of managed
> code, we are again facing the fact that (framework) dll's are not
> backward compatible (back to the future of dll hell?)

.NET DLLs are backward compatible to at least as great a degree as plain
vanilla Win32 DLLs - more so, in some ways.

-cd

Roland
Sun Oct 22 10:25:10 CDT 2006

Answering both to Göran and Carl:
I would like to share your optimisme and probably the way I pictured it was
too black-and-white,
but fact is that the vendors of the 2 libraries I've bought (1.1 versions)
are now issuing "2.0 compatible" versions.
My first trials to use the existing ones with an exe compiled towards 2.0
are causing a lot of runtime errors, so you
understand my doubts on the compatibility between both versions of the CLR.

"Roland" <roland.demeester@skynet.be> wrote in message
news:O07aYHd9GHA.4644@TK2MSFTNGP04.phx.gbl...
> Actually, I found a possible answer on my question by reading the post
> from Carl Daniel on Oct 17.
> He stated that only one version of the CLR can be hosted in a process.
> If this is the case, there are major consequenses each time the framework
> moves forward:
>
> All libraries that you bought from third parties need to upgraded, in
> plain english: you have to buy them again.
> You wil be forced to move to the latest version of the framework when you
> want to buy a library fom a third party, because it will be compiled
> against the latest version of the CLR, and it will probably only run in
> that environment.
> All libraries that you have developed yourself need to be recompiled and
> tested again. Probably you'll need to maintain several versions, unless
> you make sure that they are behaving well when running in an earlier CLR.
>
> At least there was some interoperability possible between the framework
> and activeX, but now that we entered the world of managed code, we are
> again facing the fact that (framework) dll's are not backward compatible
> (back to the future of dll hell?)
> Any comments?
>
> "Roland" <roland.demeester@skynet.be> wrote in message
> news:%23h9SU2c9GHA.3960@TK2MSFTNGP05.phx.gbl...
>> Is it possible to call a dll that was compiled against 1.1 when the exe
>> is compiled against 2.0?
>> I have bought some dll's that are compiled against 1.1 and, obviously, I
>> don't have the source code. I hate to buy all libraries again each time
>> Microsoft moves its frzamework forward.
>> Roland
>>
>
>

Jon
Sun Oct 22 14:13:01 CDT 2006

Roland <roland.demeester@skynet.be> wrote:
> John, you mean that in that case the dll is executing the code of the CLR
> loaded by the exe?

Yes. So long as the DLL doesn't rely on 1.1-specific behaviour, it
should all be fine.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too