Avoid loading external references when registering a .Net assembly

0
votes

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.

1
.netassembliescom-interopregasm
Similarish question: Dynamic load a .NET assembly with some other dll dependency - Deanna
This does not bode well, Regasm.exe does try pretty hard to avoid having dependencies involved. There's more than one way to register an assembly, it just takes writing the correct registry keys. First thing to try is to use the Regasm.exe /regfile option so you get a .reg file that you can then test with the dependency missing. A custom [ComRegisterFunction] is another way. Or just a plain installer that writes the keys directly. But do test the .reg file first. You can get a call stack for a failure from RegistrationServices.RegisterAssembly(). - Hans Passant
Thanks, creating a registry file and importing it separately was joint last resort with late binding everything and not referencing it at all. - Deanna
The ComRegisterFunction doesn't replace the whole "DllRegisterServer" equivalent but is rather called per type that needs registering, and will still hit the same assembly resolution problem. Writing direct to the registry may well be the only option. - Deanna
Hmm, as long as you have no idea why the dependency is needed you can't know if [ComRegisterFunction] is going to fix it. Show us the call stack you get from RegistrationServices.RegisterAssembly() if you want help. - Hans Passant

1 Answers

4
votes

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.