VB(A) Error when COM-DLL tries to instance NET-DLL object

1
votes

Here is my challenge...

EXCEL-VBA opens a COM-DLL that -at one place- refers to a class from a another NET-DLL. When the COM-DLL tries to initialize an object from a class (in the NET-DLL), I get an error that the method get_ContentTypeProperties has no implementation.

error message "method [...] has no implementation".

I never created the method get_ContentTypeProperties, nor is it part of the interface I'm using.

When accessing the COM-DLL via another DLL, to workaround EXCEL-VBA, it works properly. Any ideas?

UPDATE: Using a different class from the NET-Dll that implements _Worksheet Interface (not _Workbook Interface like in the original Problem) brings the same error message, but at least i found out that the "not implemented" method (PrintOutEx) being part of the Worksheet Interface from the Microsoft.Office.Tools.Excel Namespace. This interface is used by Visual Studio, with which i am creating my DLLs. But still...my NET-DLL is implementing the _Worksheet-Interface in the Microsoft.Office.Interop.Excel Namespace. Why is a method from an interface reported missing that i am not implementing?

UPDATE:
1.) According to the Process Monitor Results i see that the proper DLL is addressed and that there is no interfering Version of the DLL loaded in the GAC, e.g.
2.) I - just in case - made Excel to refer to the .NET-Framework 2.xxx, on which all the involved DLLs are based on...same error again :(

1
vb.netexcelvbadllcom
This is a DLL Hell problem, the CLR is finding an old version of your DLL, one that doesn't have the ContentTypeProperties property implemented yet. You can troubleshoot with fuslogvw.exe, log all bindings. Forgetting to re-register an assembly and not using the Regasm.exe /codebase option to keep it out of the GAC is a good way to trigger this problem. - Hans Passant
DLL Hell might be a good shot, but: Its a private NET-Assembly in the same Folder as the calling COM-DLL an the Excel-Sheet calling the COM-DLL. After a few trials i am pretty sure its the current version, but i am about to create a sample project. - hsi
The CLR has no reason to look in the same folder as the [ComVisible] assembly for the dependency. It is not in the probing path. This normally generates a runtime exception. Whatever you did to help the CLR find the assembly is probably causing this problem. Fuslogvw.exe tells you what happened, post the binding log in your question. - Hans Passant
@Regasm /codebase: it does not register the DLL in the GAC, that would be gacutil. Its storing COM-DLL infos in the Registry and creates Typelibrary if wanted (Flag: tlb). So Regasm.exe it actually reserved for COM-DLLs - hsi
@FUSLOGVW: Had no FUSLOGVW.exe on my account. Copied it. Registration with regsvr32 \windows\system32\FUSLOGVW.exe failed. Just executing brings me the GUI, but nothing happening - hsi

1 Answers

0
votes

The problem are the MS-Interfaces i am using. I cut out the Interface Implementation and it works. It seems as if Interfaces are not downward compatible.

Using e.g. _Worksheet Interface based on Microsoft Excel 11.0 Object Library (Microsoft.Office.Interop.Excel of Office 2003) throws an Runtime-Error in Office 2007 or 2010, because the Interfaces changed. In my case a missing method is reported. And the error occurs even if implementing classes are not initialized, because implementing Interface members is mandatory.

I not sure about when the check if all interface members are implemented is taking place. It seems to be the moment the -interface containing- namespace is entered.