Slashdot Mirror
"Side By Side Assemblies" Bring DLL Hell 2.0
neutrino38 writes "This is an alert for all developers using Microsoft Visual Studio 2005. At the beginning of January, Microsoft issued a security fix for Visual Studio 2005 forcing the use of new dynamic libraries (DLLs) by all applications compiled with this IDE. Basically, applications compiled with Visual Studio 2005 will not work anymore on an ordinary (non-dev) PC unless the newer DLLs are installed. And we found out that this is true on fully updated PCs. I just posted some details and some suggested fixes." Read below for some more background on Microsoft's so-called "side by side assemblies."
For those unfamiliar with the Microsoft world, native microsoft applications written in C++ rely on dynamic libraries. Two of them are infamous: MSVCRT.DLL and MFCxx.dll. Because of software evolution and security fixes, multiple versions of these DLLs were often present in the system, causing application instability. Where Linux implemented a simple suffix notation on the dynamic libraries, Microsoft created a new beast in 2001: the Side By Side assembly. These are basically DLLs with a companion XML file that identifies them. The XML file contains a digital signature and when the system binds these DLLs dynamically to an application, it checks that the signature of the DLL matches the DLL itself. When everythings runs well, this is pretty transparent. But when issues arise, it becomes excruciatingly difficult to troubleshoot and fix. DLL hell is not over.
For those unfamiliar with the Microsoft world, native microsoft applications written in C++ rely on dynamic libraries. Two of them are infamous: MSVCRT.DLL and MFCxx.dll. Because of software evolution and security fixes, multiple versions of these DLLs were often present in the system, causing application instability. Where Linux implemented a simple suffix notation on the dynamic libraries, Microsoft created a new beast in 2001: the Side By Side assembly. These are basically DLLs with a companion XML file that identifies them. The XML file contains a digital signature and when the system binds these DLLs dynamically to an application, it checks that the signature of the DLL matches the DLL itself. When everythings runs well, this is pretty transparent. But when issues arise, it becomes excruciatingly difficult to troubleshoot and fix. DLL hell is not over.
Back when Microsoft was first out selling .NET, one of the big promotions behind encouraging us to move to .NET was the 'end to .DLL Hell'. After listening to a few sessions at the TechEd event where all these sales pitches where happening, it dawned on me that Microsoft was simply replacing .DLL Hell with what could just as easily become .NET Hell. At the day's closing Q&A session I put up my hand and asked the presenters just that question. They agreed, but added, "trust us, we've learned our lessons with .DLL Hell and won't do it with .NET". Obviously the lesson wasn't fully learned!
the loader knows how to fing the right one.
With it's finger I'd assume.
Give me Classic Slashdot or give me death!
Microsoft's SxS system is pure bureaucracy. Linux's versioned DLL system is a much better and simpler solution.
WTF? Why do you think that you should be able to allocate resources in one subsystem and free them using another? Every dynamic library on any platform can have its own heap management routines. Your stupidity is laughable -- try placing the blame where the incompetence lies.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Or, perhaps the OO people are just hacks that can't be bothered to learn how to do things properly on windows. Everytime I see an open source app "ported" to Windows, it turns to crap. Yet many apps written for windows from the get go (and I'm talking 3rd party stuff) seems to work just fine.