The failure of unmanaged code(Delphi) consumes Com from .Net RRS feed

  • Question

  • We have  to access  a Com dll that is developed by C#,    when its codebase register(regasm) as local path, works fine. but when its codebase is mapped driver, it throws the error "interface not supported" by Delphi7. From FUSLOGVW.exe, find the Com DLL has bound successfully.  also I tested to use Caspol.exe to grant full trust to mapped driver, like:

    Caspol.exe -m -ag 1.2 -url file://S:\ComClass.DLL FullTrust.

    I'm wondering if the managed com dll can not be registered as mapped driver????

    *** Assembly Binder Log Entry (2013-11-8 @ 15:28:14) *** The operation was successful. Bind result: hr = 0x0. The operation completed successfully. Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll Running under executable D:\project\TestCom.exe --- A detailed error log follows. === Pre-bind state information === LOG: User = JASON-DELPHI7WI\Dev LOG: Where-ref bind. Location = S:/ComClass.DLL LOG: Appbase = file:///D:/project/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = TestCom.exe Calling assembly : (Unknown). === LOG: This bind starts in LoadFrom load context. WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load(). LOG: No application configuration file found. LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config. LOG: Attempting download of new URL file:///S:/ComClass.DLL. LOG: Assembly download was successful. Attempting setup of file: S:\ComClass.dll LOG: Entering run-from-source setup phase. LOG: Assembly Name is: ComClass, Version=, Culture=neutral, PublicKeyToken=ec829f3f15982550 LOG: Re-apply policy for where-ref bind. LOG: Post-policy reference: ComClass, Version=, Culture=neutral, PublicKeyToken=ec829f3f15982550 LOG: GAC Lookup was unsuccessful. LOG: Where-ref bind Codebase does not match what is found in default context. Keep the result in LoadFrom context. LOG: Binding succeeds. Returns assembly from S:\ComClass.dll. LOG: Assembly is loaded in LoadFrom load context.

    Friday, November 8, 2013 7:41 AM

All replies

  • Hello,

    From the error message, it seems that the Delphi7 does not support the interface.

    Do you have a try with other Delphi higher than 7?

    And for the error message “interface not supported”, please have a check link below:

    Hope it to be helpful to you.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, November 11, 2013 9:13 AM
  • Hi, Fred

       Thanks. but I'm wondering why it woks when its codebase register(regasm) as local path?  Whether is it shortcoming of manage code to expose as Com using mapped driver, and it can often throw unexpected result?

    Thanks in Advance


    Saturday, November 16, 2013 9:49 AM
  • We had the same problem with a .net 4.0 com dll  and solved it this way:

    The codebase registry entries describe where to find your dll on disk. RegAsm.exe by default uses the file:// protocol for this. As you found out, this doesn't work for visible controls in dlls on network shares. Change the codebase registry entries for your dll to use standard unc paths (\\server\share\folder1\folder2\mynetdll.dll) or mapped drive letters (Z:\folder1\folder2\mynetdll.dll). This works for visible and invisible com classes, on local drives and network shares.

    Please be aware that there is a second codebase entry in HKCR\CLSID\{<your_Guid>}\InprocServer32\<your_version_number>\. We are adjusting both of them.

    We also found that we had to use the /tlb parameter with regasm.exe to make visible .net usercontrols work.

    Our unmanaged application that uses our .net usercontrols is not written in Delphi but Microsoft Visual FoxPro 9.0 (VFP9). And we are not using .net 2.0 dlls but .net 4.0 dlls. So your path may vary.



    • Edited by Markus.W Wednesday, January 1, 2014 1:03 PM
    Wednesday, January 1, 2014 1:01 PM