locked
how .net solve Dll Hell problem? RRS feed

  • Question

  • how .net solve Dll Hell problem?

    Thursday, June 7, 2012 11:06 AM

Answers

  • Hi,

    when a dll is loaded, a dll is not loaded just by name but also by version and certificate.

    So there is no dll hell, because you can have a lot of different versions of one dll even from different vendors.

    With kind regards,

    Konrad

    • Proposed as answer by cheong00Editor Friday, June 8, 2012 1:23 AM
    • Marked as answer by Mike Feng Monday, June 18, 2012 1:42 PM
    Thursday, June 7, 2012 11:09 AM
  • 1. How .NET solved DLL Hell

    2. What is DLL Hell


    Mark Answered, if it solves your question and Vote if you found it helpful.
    Rohit Arora

    • Proposed as answer by cheong00Editor Friday, June 8, 2012 1:22 AM
    • Marked as answer by Mike Feng Monday, June 18, 2012 1:42 PM
    Thursday, June 7, 2012 11:10 AM
  • The Dll Hell problem is mostly related to Win32 code, the further back in time you go the worse it was. Prior to XP and Windows 2000 there was no protection of opertaing system Dlls. Anybody could bundle up some set of Microsoft OS Dlls and install them, the result mostly being chaos if you got it wrong. Plus there was the 9x line and the NT line, each with different versions of Dlls etc. Even later when OS files were protected, there is still issues like "I want to use an Access (or whatever) database and access it with (some data access method). How do I install <some Dll>". Somewhere there is probably a redist that you're allowed to give users to run to install some compatible set of those Dlls - that got better when nearly everything went into MDAC redist) but trying to find the package for those is still tricky. Plus of course Visual C++ users still need to redist and install the C++ runtime support for their version and SP.

    If you're all in NET you install a framework and you should be done, that's it. If you reach out into Win32 code you need to install their prerequisites, C++ support, maybe VB6 runtime etc.


    Phil Wilson

    • Marked as answer by Mike Feng Monday, June 18, 2012 1:43 PM
    Thursday, June 7, 2012 10:36 PM
  • As long as you install everything through Windows Installer, it should be good. (The installer maintains reference count for each DLL, so when the last application that uses the DLL is uninstalled, it'd be cleaned away.) It doesn't really matter how many copies of DLL of the same name is installed, as long as their hash code is different it shall coexist, therefore we no longer need to afraid using a newer version component will introduce bug to another application using the same brand but older version of the component.

    The introduction of strong named assembly and SXS is godsend for the DLL hell problem.

    • Marked as answer by Mike Feng Monday, June 18, 2012 1:43 PM
    Friday, June 8, 2012 1:29 AM
    Answerer

All replies

  • Hi,

    when a dll is loaded, a dll is not loaded just by name but also by version and certificate.

    So there is no dll hell, because you can have a lot of different versions of one dll even from different vendors.

    With kind regards,

    Konrad

    • Proposed as answer by cheong00Editor Friday, June 8, 2012 1:23 AM
    • Marked as answer by Mike Feng Monday, June 18, 2012 1:42 PM
    Thursday, June 7, 2012 11:09 AM
  • 1. How .NET solved DLL Hell

    2. What is DLL Hell


    Mark Answered, if it solves your question and Vote if you found it helpful.
    Rohit Arora

    • Proposed as answer by cheong00Editor Friday, June 8, 2012 1:22 AM
    • Marked as answer by Mike Feng Monday, June 18, 2012 1:42 PM
    Thursday, June 7, 2012 11:10 AM
  • how .net solve Dll Hell problem?

    It made a new Hell for its assembiies. 
    Thursday, June 7, 2012 2:43 PM
  • I don't believe the framework does anything to solve the problem other than maintaining consistent interfaces for the same classes across all versions of .NET (unlike the JRE).

    Visual Studio project settings in your reference paths and properties can eliminate the problem.

    A cool feature with the Visual Studio debugger is that you can step into you managed assemblies (DLLs) to debug them (assuming a pdb file is generated) even if they are in a different language.


    Dan Randolph

    Thursday, June 7, 2012 8:35 PM
  • The Dll Hell problem is mostly related to Win32 code, the further back in time you go the worse it was. Prior to XP and Windows 2000 there was no protection of opertaing system Dlls. Anybody could bundle up some set of Microsoft OS Dlls and install them, the result mostly being chaos if you got it wrong. Plus there was the 9x line and the NT line, each with different versions of Dlls etc. Even later when OS files were protected, there is still issues like "I want to use an Access (or whatever) database and access it with (some data access method). How do I install <some Dll>". Somewhere there is probably a redist that you're allowed to give users to run to install some compatible set of those Dlls - that got better when nearly everything went into MDAC redist) but trying to find the package for those is still tricky. Plus of course Visual C++ users still need to redist and install the C++ runtime support for their version and SP.

    If you're all in NET you install a framework and you should be done, that's it. If you reach out into Win32 code you need to install their prerequisites, C++ support, maybe VB6 runtime etc.


    Phil Wilson

    • Marked as answer by Mike Feng Monday, June 18, 2012 1:43 PM
    Thursday, June 7, 2012 10:36 PM
  • As long as you install everything through Windows Installer, it should be good. (The installer maintains reference count for each DLL, so when the last application that uses the DLL is uninstalled, it'd be cleaned away.) It doesn't really matter how many copies of DLL of the same name is installed, as long as their hash code is different it shall coexist, therefore we no longer need to afraid using a newer version component will introduce bug to another application using the same brand but older version of the component.

    The introduction of strong named assembly and SXS is godsend for the DLL hell problem.

    • Marked as answer by Mike Feng Monday, June 18, 2012 1:43 PM
    Friday, June 8, 2012 1:29 AM
    Answerer
  • In addition to the others, Be aware that this is a little bit different for VB developers then C# developers as the later uses default namespaces.

    If you face this problem with VB than set a default namespace using the project properties or include in all your code the namespace.


    Success
    Cor

    Friday, June 8, 2012 6:52 AM