RegAsm cannot find dependent library when registering a DLL

RegAsm cannot find dependent library when registering a DLL

• Nilesh Patel

  Other ideas:

  Try using a Microsoft program called depends.exe, the Microsoft "Dependency Walker", on your native dll, "other.dll".  Check and see that all the native dll dependencies can be found and accessed.

  One other move you can make specifically for "other.dll", something I have not tried before, is to make a PINVOKE call to the WINAPI "::LoadLibrary(...)".  This loads the native DLL library explicitly rather than implicitly from you managed COM Interop DLL assembly.  This call returns a handle.  Later you must call "::FreeLibrary(handle)" to unload the library from memory.  In this case, you just tell LoadLibrary() the path to the native DLL you want to load.  I do not know if there is a Visual C# library equivalent to force a native library to load explicity.  But this should work.  Actually, this is a good tool to use at runtime to make sure all dependent application extension DLLs are present and loaded into memory successfully.  Any handle that returns a failure can then flag a serious error and force a shutdown until an administrator can fix the problem.  This is a useful tool for application executables and application extension DLLs which are dependent on other DLLs.

  Try this out and let me know if it fixes the problem.

  James

  
  

• Mark Freeman

  Sorry, I won't be able to get back to this for a day or two. Thanks again!
  

• Ross B.

  Hi Karoly:

  I assume the following:

  • You are using regasm.exe to register myplugin.dll, a managed application extension.
  • Your application calls to and has a dependency on Other.dll.
  • I assume that Other.dll is another managed assembly that is not accessed by COM Interop.

  You should look at the following options:

  • Option 1: Add a temporary or permanent strong name key to the Other.dll assembly and the load the assembly into the GAC. The GAC is like the old Windows\System and WIndows\System32 directories for native dlls. The assembly in this case should be easily found and publically available. Then add a temporary or permanent strong name key to the myplugin.dll COM Interop assembly. Load this into the GAC and then register the assembly with RegAsm.exe.
  • Option 2: Load both files into the same directory as private assemblies. Then add a temporary or permanent strong name key to the myplugin.dll COM Interop assembly; this step is optional but recommended. Register the myplugin.dll COM Interop assembly with RegAsm.exe, but use the /codebase switch. It is when using this switch that Microsoft recommends using a strong named assembly. This switch loads information about a private COM Interop assembly into the registry just as if you had loaded the assembly into the GAC. This is like a GAC "go-find" to a private directory.
  • Option 3: Override option 1 and option 2 by forcing the running of a local or private assembly even though one has been registered with RegAsm.exe. This requires the create of an empty file with notepad; you name this file as "myplugin.dll.local". This file acts as a marker and tells the CLR to look for a local copy of the COM Interop DLL versus one that has been registered to the assembly. This comes in handy during development. This is known as SxS or using Side-By-Side assemblies for COM Interop. Your registry may have become corrupted; so this is a good this to try out.
  • Option 4: Try using the /unregister switch with RegAsm.exe. Sometimes this can fix or clear out bad information in the registry with having to manually do it. Manual work on the assembly is not an easy task. You might need to be conscious of where you registered your assemblies and use the same path to the DLL in unregistering the assembly with RegAsm.exe. This is especially true if you altered the GUID on the components.
  • Option 5: Last resort, not always good for the registry, but do change the GUID in the good and re-register the component.

  I hope this helps.

  James

  Dallas, TX

  P.S. Microsoft has a utility called COMInfo.exe which helps with tracking information to the registry. Call Microsoft support and they will sent it to you for free. Also, check www.sysinternals.com. They have RegMon.exe and FileMon.exe which track registry and file events. This might let you know if you have a system problem such as access privileges. It will let you know if you have "Access Denied".

  
  

• pappascd

  One other note:

  It is possible your dependency has another dependency in and of itself. Your error may not be a clear indication of the problem. I have read of this scenario in the past.

  James

  
  

• Thegamingchoice

  Yes, this last scenario seems to be the case, as I get the following error when attempting invoke RegAsm on the other.dll:

  RegAsm : error RA0000 : Failed to load 'other.dll' because it is not a valid .NET assembly

  This dll is one of the core dll's for the chat program. It is used as a project reference for building my plugin dll in C# Expr, so I'm sure if it's ok there, it should be ok here, no

  As I've said before, I'm not very familiar with the concepts involved here, like what an assembly is and what would make it valid or not.

  What exactly does the C# Expr IDE do to enable the chat program to load this plugin It works just fine, so the dll registration code works the same, right

  Thanks for your help!
  Karoly

  
  
• RegAsm cannot find dependent library when registering a DLL