|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
A question on 1.1 and 2.0 interoperabilityIs 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 <roland.demees***@skynet.be> wrote:
> Is it possible to call a dll that was compiled against 1.1 when the exe is Yes, that should be fine. There are a few changes between 1.1 and 2.0 > 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. 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 - <sk***@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 John, you mean that in that case the dll is executing the code of the CLR
loaded by the exe? Show quote "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MPG.1fa5698c8c9a159a98d56b@msnews.microsoft.com... > Roland <roland.demees***@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 - <sk***@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 <roland.demees***@skynet.be> wrote:
> John, you mean that in that case the dll is executing the code of the CLR Yes. So long as the DLL doesn't rely on 1.1-specific behaviour, it > loaded by the exe? should all be fine. -- Jon Skeet - <sk***@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 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? Show quote "Roland" <roland.demees***@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 > 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: Show quote > 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.demees***@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 wrote:
> Actually, I found a possible answer on my question by reading the That's true.> 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 That's not true.> framework moves forward: 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 No, not so.> plain english: you have to buy them again. > You wil be forced to move to the latest version of the framework when That will be true to some extent, just as it is with Windows versions. > 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. 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 Need to be recompiled? No. You'll probably want to recompile them for the > 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. 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 ..NET DLLs are backward compatible to at least as great a degree as plain > 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?) 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. Show quote "Roland" <roland.demees***@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.demees***@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 >> > >  |
|||||||||||||||||||||||
Other interesting topics