We have a .Net DLL that is available via COM interop which acts as a wrapper for a 3rd party's .NET library.
This 3rd party library isn't needed in the vast majority of situations, so isn't included in our setup, but our wrapper DLL is.
The problem comes when we try and register our wrapper DLL (with regasm) which fails with:
RegAsm : error RA0000 : Could not load file or assembly '3rdParty.Application.Library, Version=5.3.0.0, Culture=neutral, PublicKeyToken=0123456789abcdef' or one of its dependencies. The system cannot find the file specified.
As our wrapper already reports meaningful errors when it can't load the 3rd party library, is there a way to make regasm NOT try and load it (like /delayload) so our application can load it and get the error at run time?
This article suggests that assemblies are already delay loaded, but that doesn't seem to apply when registering COM interop assemblies.
Typically .NET dependencies are delay-loaded, but the delay is until static construction of a type containing a method or field that references something in the dependant assembly. And since RegAsm uses reflection to walk through all types in the assembly, this will always load all dependencies.
One thing that you may be able to do to mitigate this is to break up your COM assembly, putting anything that references the non-distributed library into a separate (non-COM) library that you always distribute. It's likely that this second library will be automatically loaded as RegAsm scans the first, but it shouldn't load the third as long as you keep its types out of the first assembly.
Ideally, keep the COM-visible types as thin as possible, with the real implementation in a separate .NET assembly. This also means that .NET clients can skip the COM layer entirely.