>I am trying to use an third party .NET DLL in VFP. How to instantiate it?
>
>How to register .NET DLL?

Hi Antonio,

If the .NET DLL is explicitly designed to expose as a COM object and is registered for COM then you can instantiate it directly from VFP. However, that tends to be rather rare for third party controls/libraries to be COM exposed.

If it's not, then you need an intermediary to load the .NET runtime and load the assembly and instantiate the .NET object and return it to you via COM. You can create the Intermediary in .NET, expose it through COM and then proxy the original components through the intermediary. You can do this through COM (if you're willing to put up with COM registration of your component) or you can implement a proxy that creates the .NET runtime directly inside of FoxPro and avoid the hassle of .NET COM registration.

I wrote about how to host the runtime in FoxPro some time ago:
Hosting the .NET Runtime in Visual FoxPro

This approach basically allows you to bypass COM invocation and directly load .NET components from FoxPro.

However, while this works there's usually much more that you need to get this to work properly. Like the ability to access static values, enums, array/collection manipulation, access to .NET structures and deal with various types that don't work directly when used through COM Interop in FoxPro.

FWIW, I've built a wwDotNetBridge library for West Wind Client Tools some time ago which incorporates what I posted above along with a large library of helper methods and objects. These methods and objects allow for indirect invocation of .NET methods and members from within .NET and let you access most functionality in .NET that .NET provides from FoxPro. The library can also be used through regular COM Interop with COM activation to provide the same functionality without having to host the .NET runtime in FoxPro (as is the default for wwDotNetBridge).

You can find out more here:
Class wwDotNetBridge Docs


The idea is basically that you can load assemblies through the proxy, then use the returned COM object directly as much as possible. For all the edge cases that VFP doesn't support or doesn't support well, the proxy provides methods to deal with the limitations via indirect invocation and assignments.

It's worked really well for me and many of our customers. A lot of the work I do involves interfacing with a large variety of complex Web Services and we use .NET Web Service proxies in combination with wwDotNetBridge to access the many features of .NET types that don't work well over regular COM Interop. It's really exposed a lot of the edge cases that just don't work with regular COM interop and require indirect invocation...

I've been meaning to write an article about how all of this works and publish the basic library outside of WWClient but I've been too busy recently to get to it unfortunately...

Hope this helps,