0

I discovered that with this syntax, I would get a compile error:

importlib("MSADDNDR.dll");

The error given would be:

error MIDL2337 : unsatisfied forward declaration : _IDTExtensibility2 [ Coclass '_Extension'  ]

But that's a lie, kind of. Looking earlier in the output, we see this:

warning MIDL2015 : failed to load tlb in importlib: : MSADDNDR.dll

So, if we change the attribute to include the full path:

importlib("C:\Program Files (x86)\Common Files\Designer\MSADDNDR.dll");

It will now compile correctly.... but... this is referencing a 32-bit DLL. Suppose I want to cross compile? So I specify /amd64 option to the MIDL. This still compiles successfully. I cannot find any documentation that may suggest that using full path to a potentially wrong bitness DLL for importlib would cause problems.

Can anyone else confirm or deny if there are potential problems or if there might be a better approach to avoid embedding full path?

Interestingly, when I load the generated .tlb file in the oleview, the full path aren't there anymore; which suggests this is an non-issue but I'd like to make sure that is so.

this
  • 1,406
  • 11
  • 23
  • 1
    I'm pretty sure type libraries are bitness-independent; the same one works for both 32- and 64-bit environment. The fact that it's attached as a resource to a 32- or 64-bit DLL is irrelevant. That said, you can use [`/I` command line option](https://msdn.microsoft.com/en-us/library/windows/desktop/aa367328.aspx) to tell MIDL where to search for imported libraries, rather than hard-coding the path into the source. – Igor Tandetnik May 05 '18 at 19:45
  • My experience always has been the opposite. We can provision a bitness-independent CLR DLL but we must always provide 32-bit and 64-bit TLB files separately for the same CLR DLL; both `regasm.exe`, `tlbexp.exe` as well the midl provide options for generating either 32-bit or 64-bit TLB file. The registry even has separate entries for `win32` &`win64`. That's why it seems unintuitive that a full pth to a 32-bit DLL/TLB in an IDL wouldn't have any impact on the TLB being generated. Good to know RE: `/I` - not sure how that helps since different paths are needed for 32/64 versions. – this May 06 '18 at 05:13
  • My guess is that it is a non-issue, because COM doesn't care much about directories. Usually, it will find a type library using the registry, based on the GUID, which is why COM components and type libraries have to be registered. However, I agree with Igor that it would be better to use the /I command line option, than to hard code the path in the source code. – Phil Jollans May 06 '18 at 07:51
  • Re: how it helps. Whatever build system you use that sets `/amd64` option would also set `/I` option to point to 64-bit directory; while the 32-bit build would instead point to 32-bit directory. – Igor Tandetnik May 06 '18 at 13:59
  • @PhilJollans if it were using registry, then it shouldn't have needed the full path in the first place, no? That said, I will definitely use `/I` instead of embedding full paths. – this May 06 '18 at 16:44

0 Answers0