DLL Hell - What is that ?
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
.NET allows multiple versions of an assembly to coexist using versioning. cheers, Chris Maunder
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
The single most annoying case of DLL hell I have had to deal with was when M$ was releasing service packs for NT and VC and we built our app with the latest version of MFC. Well, they updated MFC42.dll to a rev that was not the same as the default OS installation so our latest build did not work with most systems. The old "ordinal WXYZ not found" error was what we got. I almost had to get on a plane over this issue and it really pissed me off. I still don't understand why they didn't increment the version number of the DLL because it was not forward compatable. We ended up having to distribute the DLL also so what were they thinking ? In my opinion, they weren't.
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
There was a very amusing WDJ editorial about six months ago about how often M$ have 'solved' DLL hell. Christian I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOz
I live in Bob's HungOut now
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
http://www.computerworld.com/cwi/story/0,1199,NAV47-71-366-1718\_STO65533,00.html thought you guys might be interested in this article. I've never thought about the "problem" quite in these terms though :-) Senkwe Just another wannabe code junky
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
Ravish wrote: The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . There can be more than one CLR on the same machine and components from one CLR can interact with the components in the other version. It wont happen sooner but its a definite possibility when they go for a next version of CLR. Cheers Kannan
-
.NET allows multiple versions of an assembly to coexist using versioning. cheers, Chris Maunder
The best thing is not having to put 1000s of DLLs in the system32 directory Nish Sonork ID 100.9786 voidmain www.busterboy.org If you don't find me on CP, I'll be at Bob's HungOut
-
http://www.computerworld.com/cwi/story/0,1199,NAV47-71-366-1718\_STO65533,00.html thought you guys might be interested in this article. I've never thought about the "problem" quite in these terms though :-) Senkwe Just another wannabe code junky
I found that article interesting. I especially liked the following paragraph: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." I was reminded of some of the the help in MSDN. Sometimes I wonder if they are deliberately trying to be abstruse. "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
-
I found that article interesting. I especially liked the following paragraph: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." I was reminded of some of the the help in MSDN. Sometimes I wonder if they are deliberately trying to be abstruse. "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
Daniel Ferguson wrote: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." This argument is completely stupid (or am I the stupid here ?). It's non-sense. It's like saying Ferrari makes faster cars to make it difficult for Sony creating a CD-player that plays music at 250 miles/hour on slower car brands. So, if you want to hear music at this speed, you want a Ferrari. But THIS is not the point. If you want DRIVING at this speed, you want a Ferrari. If Sony ever makes a CD-player that only works at this is speed, it's a Sony problem, not Ferrari's monopolistic view of the world! If the feature is Windows-specific and your software depends on it, it IS a Windows-specific software! It's YOUR fault, not MS! If the feature is not Windows-specific, so your software is simpler to deploy on other platforms. This is pretty obvious and clear. Crivo Automated Credit Assessment
-
Daniel Ferguson wrote: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." This argument is completely stupid (or am I the stupid here ?). It's non-sense. It's like saying Ferrari makes faster cars to make it difficult for Sony creating a CD-player that plays music at 250 miles/hour on slower car brands. So, if you want to hear music at this speed, you want a Ferrari. But THIS is not the point. If you want DRIVING at this speed, you want a Ferrari. If Sony ever makes a CD-player that only works at this is speed, it's a Sony problem, not Ferrari's monopolistic view of the world! If the feature is Windows-specific and your software depends on it, it IS a Windows-specific software! It's YOUR fault, not MS! If the feature is not Windows-specific, so your software is simpler to deploy on other platforms. This is pretty obvious and clear. Crivo Automated Credit Assessment
No need to get so excited and jump all over me because I said something that questions the way MS does things. :omg: I think you missed my point. I wasn't referring to specific features of Windows or any other OS, or even trying to compare Windows to any other OS, what I'm saying is that the implementation of some features is more complex than they need (or should) be, and why is this? :suss: "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
-
No need to get so excited and jump all over me because I said something that questions the way MS does things. :omg: I think you missed my point. I wasn't referring to specific features of Windows or any other OS, or even trying to compare Windows to any other OS, what I'm saying is that the implementation of some features is more complex than they need (or should) be, and why is this? :suss: "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
Excuse me, it wasn't my intention to seem agressive (maybe it's my poor english, I'm a native portuguese speaker). Again, I disagree: I've seen tons of people having problems with .o and .so files on Linux. Search for glibc on the web and you'll see what I mean. Crivo Automated Credit Assessment