DLL Hell with COM modules

[wriedmann]

Hello all,
in one of my (VO) applications I'm using several COM modules, and with a new version of a used library I had the problem that I had a classic case of DLL hell: two libraries I used had dependencies on different versions of the System.Threading.Tasks.Extensions.dll library.
After a few hours of searching I found a very interesting solution: put them in different subdirectories of the application directory and then use the AssemblyResolve event to redirect the load to the correct path:

Code: Select all

protected method AssemblyResolve( oSender as object, oArgs as ResolveEventArgs ) as Assembly
local oAssembly as Assembly
local cFileName as string
local cAsmFile as string

if oArgs:Name:Contains( ".resources")
	return null
endif

    // check for assemblies already loaded
oAssembly := AppDomain.CurrentDomain.GetAssemblies():FirstOrDefault( { a => a:FullName == oArgs.Name } )
if oAssembly != null
    return oAssembly
endif
cFileName := oArgs:Name:Split( ',') [1] + ".dll":ToLower()
cAsmFile := Path.Combine ( ".","AlpiComLib", cFileName )

try

return System.Reflection.Assembly.LoadFrom( cAsmFile )

catch // oEx as Exception

end try
return null

You have to register as follows:

Code: Select all

AppDomain.CurrentDomain.AssemblyResolve += AssemblyResolve

That way you can also change the loading path for other runtime DLLs.

Wolfgang

[NickFriend]

Hi Wolfgang,

I've had similar issues at times. You can probably also use a binding redirect in an assemblyname.exe.cfg file, to avoid distrbuting multiple versions of the file. Something like this:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

This makes any request to use the file redirect to the V4.2.0.1 file.

Nick

[wriedmann]

Hi Nick,
I saw that also, but since the DLLs that are loading the conflicting DLLs are not mine, I just preferred to to don't change the manifest.
Wolfgang

[ArneOrtlinghaus]

I remember the phrase of some enthusiastic programmer colleagues over 10 years ago on a VO-Conference:
Dotnet is so great: DLL Hell does not exist anymore. All Dlls load the correct version they need. ... and so on. (Runtime errors should also be nearly excluded)

But this is a joke.

Thankfully DLL Hell has diminished very much in the last years, not only because of Dot net, but because of many changes in the operating systems and in the programming methods. One of the worse problems were the dlls that had to be registered for com object usage. Fortunately they diminish. Even Crystal Reports with the Runtime version 13 for Dotnet has succeeded getting rid of these dll class registrations.
Arne