0

I often reference strong-named 3rd-party DLLs in my projects. When I later deploy my DLL into the bin folder on a server containing those same 3rd-party DLLs, but of a newer version, it blows up with this error:

Could not load file or assembly 'SomeThirdPartyAssembly.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=5cb6ee67c115baf6' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I have carefully read these 2 related SO posts:

Assembly Loading Version Mismatch: Why is it loading?

How exactly does the "Specific Version" property of an assembly reference work in Visual Studio?

The interface/signatures of the 3rd-party DLL functions haven't changed, and in reality there's no reason for this to blow up (in my perfect world). In my project I always set the property Specific Version to False, but it seems that's purely a compile-time thing and not a run-time thing. My custom DLL is not strong named.

Question: Is there any way I can make my custom DLL not blow up when (at run time) it references a 3rd-party DLL of a different version from what it was compiled against?

HerrimanCoder
  • 6,835
  • 24
  • 78
  • 158
  • Normally if you specify these dependencies using NuGet packages instead of raw DLLs, everything works out in my experience - whether that's via automated assembly binding redirects, or automatically generated asset files for .NET Core. If you *can* use NuGet packages (and ideally SDK-style project files) it's likely to make your life easier. – Jon Skeet Jun 09 '21 at 17:13
  • I was hoping to avoid NuGet, but I do see your point - and thank you for the suggestion. – HerrimanCoder Jun 09 '21 at 17:23
  • You can remove the strong naming from the third party DLLs. Besides that, there's no way afaik, because having version checking is one of the intents of strongnaming. – riQQ Jun 09 '21 at 22:17
  • Makes sense, thank you. – HerrimanCoder Jun 10 '21 at 19:43

0 Answers0