locked
Registering a .net dll for com interop with VFP9 app RRS feed

  • Question

  • I have a dll provided by a third party which I access from a VFP9 app. This dll provides an API to communicate with a c#.net app. On my two development machines, I run the C# app and then register the api dll using regasm with the /codebase and /tlb switch. From that point on, I can create the objects in my vfp app and communicate with the api dll successfully. I can pass information to the C# app using the api dll and events in my foxpro app fire as they should from the c# net app via the api dll. On my workstations, I had the api dll originally registered out of another directory (for code test purposes only), not the foxpro app directory. I did, however, put a copy of the dll and tlb file in the app's directory and register it using the same process from there. It works on my two development machines. It also works from two other test machines.

    However, on just about every other workstation, I cannot get my foxpro app to work with api dll. If fails everytime I issue the createobject() command. Yet, if I search the registry, I can see that the api dll is registered in that directory. All machines have XP SP3 and have the same foxpro files installed as far as I can see. The api dll has the dotnet framework 2.0 as a dependency and I installed the 3.5 just to be safe (it installs all of the previous versions). When I manually issue regasm it is successful. It works on my daughters pc which has nothing but windows xp, the dotnet framework, the api dll, and my foxpro test app with the foxpro runtime files. Yet it doesn't work on other machines with a full version of foxpro and xp and the dotnet framework.

    Any ideas anyone? The provider never worked with com interop before so they are no help really. So far they have made changes to the api dll as I've requested when I tell them what the requirement is in order for our app to interface with theirs (basically how to build a com interop assembly in dotnet).

    The api dll does NOT have a strong name so it does not go into the GAC. This has not been an issue on some workstations though (including my two development machines and my daughter's test pc).

    When I was able to communicate with it successfully from my foxpro app from my two development machines and two other non-development machines (no vfp except for the runtime files) I figured it would work on all. That is not the case.

    Any ideas are welcome!

    • Edited by tcCoder Wednesday, July 22, 2009 12:54 PM
    Wednesday, July 22, 2009 12:51 PM

Answers

  • Between IDE and EXE paths, and 'set's might be different. Additionally the identity trying to CreateObject() might be different - I don't know really know if that can be different if you are not using impersonation API or something like internet guest account.

    That shouldn't have any dependancy to VFP, did you try creating it say from an HTM using JScript?
    Friday, July 24, 2009 11:54 AM

All replies

  • Tracy,
    First question would be "Are the failing machines have 64 bits OS" and connected with that did you explicitly target x86 while compiling your C# dll.
    Wednesday, July 22, 2009 1:39 PM
  • Every machine is Windows XP SP3 (32 bit).  Every machine has the full net framework installed (1.1-->3.5). I don't compile the c# dll, that is provided to me by the 3rd party.  I just interface with it via com interop from VFP.
    Wednesday, July 22, 2009 2:42 PM
  • Wednesday, July 22, 2009 5:30 PM
  • Thanks but I read that months ago and Rick's papers as well. It is working on most machines, but not on all so I need to figure out what is different between the machines and it isn't anything obvious that I can see.

    I appreciate your reply though, thanks!
    Wednesday, July 22, 2009 8:20 PM
  • Every machine is Windows XP SP3 (32 bit).  Every machine has the full net framework installed (1.1-->3.5). I don't compile the c# dll, that is provided to me by the 3rd party.  I just interface with it via com interop from VFP.

    Tracy,
    It is hard to find out and I feel your pain.  All DLLs I have created was strongly named and I can say that those DLLs are working on numerous machines from XP SP2 and later (somewhat assuming they are working, otherwise customers would make me know it doesn't on day one).

    Can you point the provider to:

    http://cfx.codeplex.com/

    There they would find all COM building steps (besides others).
    Thursday, July 23, 2009 4:52 PM
  • I discovered today that it does work if I run the executable from within the VFP ide.  Some of the workstations have the full verion of vfp9 installed and as a test, I launched the excutable from the command window inside the VFP9 ide.  It works fine.  However, even on those machines with VFP9 installed, if I try to run the excutable outside of the IDE - even with the runtimes in the same directory - it bombs on the CREATEOBJECT().  I can view the items logged in the procmon that show identical entries for when it works and when it doesn't.  It reads the registry entries fine in both cases.  Yet it will not work outside of the vfp9 ide.

    So what is missing in my executable or in the runtimes that would cause it to fail when running the exe outside of the IDE?  I set the default location and the path identically in vfp under both situations before the exe launches.
    Thursday, July 23, 2009 6:22 PM
  • Between IDE and EXE paths, and 'set's might be different. Additionally the identity trying to CreateObject() might be different - I don't know really know if that can be different if you are not using impersonation API or something like internet guest account.

    That shouldn't have any dependancy to VFP, did you try creating it say from an HTM using JScript?
    Friday, July 24, 2009 11:54 AM
  • No I haven't, but I may try that today!  Thanks for the idea.
    Friday, July 24, 2009 12:11 PM
  • I got this working.  My install and registration was working, but the 3rd party's install overwrote it afterwards and removed the com interop registration.  I had to create my own install package (used VS2008) for the 3rd party dlls and tlbs to register them for com interop and then include that path in my vfp app where the class is defined.  I had to contact the 3rd party vendor of the dlls to make sure that I installed the dll in the same place they install it so another registration doesn't occur when they do their install that would remove the com interop.  We had to workout a list of steps for the customer so that the install of both of our apps doesn't stop the other one from working.

    Tuesday, September 8, 2009 1:36 PM