|
O tempo passa, o tempo vooa e continuamos a ver problemas de compatibilidade com bibliotecas distribuídas nas ferramentas de desenvolvimento da MS:
Vejam esse post do [http://slashdot.net] , é lamentável, um upgrade no Visual Studio 2005 altera a compilação e por sua vez a compatibilidade com DLLs pré-existentes. Isso sem contar que desenvolver aplicações self-contained ainda é praticamente impossível com .Net, o usuário final continua preso a ter um sistema operacional compatível com a aplicação e não o contrário.
É interessante pq este problema exemplifica claramente a contínua fragilidade de aplicações baseadas no Visual Studio e fortifica a adoção do uso de máquinas virtuais que abstraem a configuração do SO. Isso sem contar que quando uma IDE interfere no modelo de compilação, o profissional passa a ter mais uma variável de risco em seu software, a IDE, pois seu código não depende tão somente da linguagem na qual foi codificado.
Post:
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.
(06/10/2009)
Bibliografia recomendada:
|
|
|
