0

I am currently working on a C# project in which I load libraries using Kernel32->LoadLibrary() and also integrate (statically linked ???) libraries in VS 2022 17.1.1.

Now I read information about the libraries, which were integrated using LoadLibrary(), simply with Kernel32->GetModuleFileName() and FileVersionInfo.GetVersionInfo().

But I don't have access to the path of the statically linked libraries in the project to get more information using FileVersionInfo.

For example, I tried with

typeof(__NAMESPACE___.__ONE_EXEMPLE_INTERFACE_OR_CLASS__).Assembly.Location

to get the path, but the Type's assembly is my own application. Probably because the library is integrated with "embedded interop types". But I can't change that. Is there another way?

By the way: If I look up the full path myself (e.g. with a process monitor) and determine information using FileVersionInfo, everything works. But the path can vary, so I would like to determine it at runtime.

One of the libraries which are statically linked / embedded in VS:
Resolved: true
Filetype: ActiveX
embedd Interoptypes: true
isolated: false
local copy: false
strong name: false

I tested LoadLibrary + GetModuleFileName. But the library is not found by the Kernel32 / GAC. Then I tried to determine the path using the type of a class and the associated assembly. But the assembly is my own program.

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
DrDoom
  • 1
  • 1
  • 1
    One important question is: are these namanged (.NET) assemblies? Or unmanaged (Win32) DLLs? – Klaus Gütter Jan 11 '23 at 12:46
  • Hallo Klaus, grüße nach Nürnberg. I could not determine whether it is a managed or unmanaged dll. my dependancy walker doesn't load the dll. How can I verify that? – DrDoom Jan 11 '23 at 13:09
  • See here: https://stackoverflow.com/questions/5275985/is-this-dll-managed-or-unmanaged – Klaus Gütter Jan 11 '23 at 13:20
  • i check that later. the dumpbin is missing on my current pc. – DrDoom Jan 11 '23 at 13:40
  • It is the job of the COM runtime to locate and load the native library, it uses the registry to do so. That's why such a library needs to be registered, that writes the registry keys. Technically you could read those some registry keys to find the path to the file, HKLM/Software/Classes/CLSID/{guid} key. But such code will be brittle due to its dependency on the {guid} and can completely fail when the library is located on another machine. Best to not do this. – Hans Passant Jan 11 '23 at 16:34
  • Ok, I think I'm at a dead end. The identity / ID "{E1FE6A26-A628-11D4-BB88-0001020E6173}" cannot be found directly via HKLM....CLSID. Only via TypeLib child keys. The name of the linked library in VS (Interop.FRAMELib) cannot be found either. With WMI (Get-WMIObject Win32_ClassicCOMClassSetting) I was able to list all COM objects and also find the respective DLL "LibFramex64.dll". However, I would first have to query the DLL full filename via WMI and then determine the version via FileVersionInfo. – DrDoom Jan 12 '23 at 09:40
  • I'm going to do it now, after all, by using the DLL's internal function to determine the version. Unfortunately, it costs computing time but is more robust and reliable. it's a pity that .net doesn't offer any help functions to analyze com objects / currently loaded references. Thanks again. – DrDoom Jan 12 '23 at 09:40

1 Answers1

0

I have now developed a workaround. maybe it will help others too:

Instead of using the CLSID directly, I collect the data as follows.

  1. Read in HKCR->"Name of the COM object" -> "CLSID" -> Default-Value

  2. If there is the key HKCR->"Name of the COM object" -> "CurVer", I read in HKCR->"determined CurVer of the COM object" -> "CLSID" -> Default-Value

  3. With the determined CLSID I read the respective DLL full file path in HKCR -> "CLSID**{CLSID}**\InprocServer32" -> Default-Value

  4. And then I read the product version with FileVersionInfo(...).

  5. If there is an error in the previous determination, I load the COM object (unfortunately computationally intensive) and read the version with internal functions. This works very quickly after the first tests and should be relatively robust.

as a note: i read registration information from HKCR as it mixes CLSID's and Classes from HKLM and HKCU

DrDoom
  • 1
  • 1