>>>
>>>I can see it in the object browser in vfp on those systems that have the full developer version of VFP. On some it will communicate, and others not. What doesn't make sense is that it communicates fine on some machines with no vfp (only the runtimes) but not on others as well. When I check the registry the entries are there and the location of api dll is included.
>>>
>>>What could possibly be different between the machines that work and the ones that don't?
>>Too much to guess correctly... Just imagine the dll trying to be able to log to a specific directory and failing gracelessly if no dir or rigths exist.
>>Which is the reason I'd check first without COM thrown in.
>>
>>regards
>>
>>thomas
>
>Hmmm, you've given me something to think about actually,,,,,,thanks!

What error do you get when you do the CREATEOBJECT()?

I have had a lot of painful experience getting .NET objects to work from VFP myself lately. Just like your problem they worked fine on my development system and a few others but failed elsewhere. I found that if the .NET constructor throws an exception, CREATEOBJECT() will not report the error well. Its even worse if you are dragging visual .NET objects to VFP forms. In that case an exception in the constructor will cause VFP to give "Class not registered" errors even though they are properly registered.

In my case, since they are my own .NET classes, I moved some of my code out of the constructor into another method. I then have my VFP code call that method to finish initialization after the CREATEOBJECT() call. This reduced the chance of an exception during CREATEOBJECT(). The exceptions in the method call are reported better.

You could create a c# factory object and then have VFP call methods on it to get the .NET objects you need. That would keep your 3rd party code from throwing exceptions during CREATEOBJECT().

Brooks