In .NET gelöste bzw. noch ungelöste DLL Probleme
In .NET kann jedes Programm eigene Bibliotheken verwenden und sie im Stammverzeichnis des Programms ablegen.Alternativ können Assemblies aber auch zentral im Global Assembly Cache (GAC) abgelegt sein. Dieser verwaltet sie einschließlich einer vom Compiler erzeugten Versionsnummer, so dass garantiert ist, dass jedes laufende Programm stets nur die Version der DLL zugewiesen bekommt, mit der die Entwickler es verknüpft und getestet haben.
Leider bedeutet all das nicht, dass Applikationen, die .NET nutzen, nicht auch in Installationsprobleme mit DLLs laufen können. Die aber sind dann folgender Art:
- If an assembly exposes native DLL interfaces to other applications these DLLs will be loaded into the EXE and if the EXE already uses the .NET-Framework, the now loaded DLL is forced to use this version of the framework (because loading two or more versions of the .NET Framework into one process is not possible). So if you built your DLL for version 1.1 and the host process was built for version 2.0, your DLL will operate against the 2.0 framework version (though it was meant to operate against 1.1).
- Umgekehrt gilt: A DLL built for .NET cannot be loaded into an application built for an earlier .NET version.
- Dies hat, wie Jochen Kulmbach schreibt, böse Auswirkungen auf COM Interoperability: If you register your .NET assembly
with regasm and the EXE uses
a COM object using .NET v1.1 and if the EXE then also tries to load your COM object (after loading the other one),
then your assembly will fail to load if it was compiled against v2.0.
Siehe auch:
stw3857NETDLLP — NET . DLL . Probleme — News?
Mehr + B G E + S H A + More