4

I developed a .NET class library with the following characteristics:

  • .NET 4.0, Any CPU
  • References adodb.dll from the .NET Primary Interop Assembly folder
  • Builds with Embed Interop Type set to true (default)
  • Exposes an ADODB.RecordSet for consumption by COM.

I expose the assembly to VBA via a VSTO AddIn. It runs fine on my machine, but on client machines my assembly throws a System.TypeLoadException when it tries to access the Fields property of a RecordSet.

public Recordset Test() {
    Recordset result = new Recordset();
    result.CursorLocation = CursorLocationEnum.adUseClient;
    Fields resultFields = result.Fields; // EXCEPTION THROWN HERE.
    ...
}

Exception message:

Could not load type 'ADODB.FieldsToInternalFieldsMarshaler' from assembly 'MyCompany.MyProduct.Interop.Com.

Failing clients: Win XP/32, Win 7/64. Neither have local admin rights. Both have .NET 4.0

Update: This Post describes my problem. The accepted answer (late binding) did not work for me, but Bob's answer did (do not embed the Interop).

As soon as I set Embed Interop Types to False, everything started working as If by magic.

So my question has changed to "Why does embedding the interop not work?" I thought that was the best practice to avoid problems on client machines.

Community
  • 1
  • 1
mr_plum
  • 2,448
  • 1
  • 18
  • 31
  • 2
    adodb.dll is not a squeaky clean COM interop library. It contains .NET classes to handle marshaling, FieldsToInternalFieldsMarshaler is one of them. The Embed Interop Types feature can only embed pure COM interfaces, not .NET classes. No build warning either, your code doesn't use these classes directly. – Hans Passant Apr 05 '13 at 19:38
  • possible duplicate of [ADODBCould not load type 'ADODB.FieldsToInternalFieldsMarshaler' from assembly](http://stackoverflow.com/questions/5666265/adodbcould-not-load-type-adodb-fieldstointernalfieldsmarshaler-from-assembly) – user692942 Feb 18 '15 at 10:49

0 Answers0