A question on 1.1 and 2.0 interoperability

  • Thread starter Thread starter Roland
  • Start date Start date
R

Roland

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 said:
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.
Click to expand...

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.
 
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?
 
John, you mean that in that case the dll is executing the code of the CLR
loaded by the exe?
 
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 said:
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.
Click to expand...

That's true.
If this is the case, there are major consequenses each time the
framework moves forward:
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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?)
Click to expand...

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

-cd
 
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 said:
John, you mean that in that case the dll is executing the code of the CLR
loaded by the exe?
Click to expand...

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