DLL Hell with COM modules

Public forum to share code snippets, screen shorts, experiences, etc.
Post Reply
User avatar
wriedmann
Posts: 3688
Joined: Mon Nov 02, 2015 5:07 pm
Location: Italy

DLL Hell with COM modules

Post by 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
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
NickFriend
Posts: 248
Joined: Fri Oct 14, 2016 7:09 am

DLL Hell with COM modules

Post by 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
User avatar
wriedmann
Posts: 3688
Joined: Mon Nov 02, 2015 5:07 pm
Location: Italy

DLL Hell with COM modules

Post by 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
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
User avatar
ArneOrtlinghaus
Posts: 398
Joined: Tue Nov 10, 2015 7:48 am
Location: Italy

DLL Hell with COM modules

Post by 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
Post Reply