wwDotNetBridge recommended for extension of VFP with .NET assemblies

[Olaf Doschke]

Maybe worth another article, though you already find several mentionings of this bridge of VFP to the .NET world.

What is it?
The wwDotnetBridge allows you to use DotNet assemblies, no matter if native (.NET Framework, third party or self written), because it works without the somewhat cumbersome definition of COM visibility of classes and also works without any registration with regasm.

It's quite easy to use, eg as in

Set Procedure To ...\wwdotnetbridge.prg && part of the download

loBridge = Createobject("wwDotNetBridge","V4")
loBridge.LoadAssembly("...Assembly.dll")
loIO = loBridge.createinstance("Assembly.Class")[class]

The SET procedure allows to use the wwDotNetBridge class, which initialises some things, loads a functionality of the clrhost.dll and starts a .NET Framework version, by the 2nd line creating the loBridge object. The next step already loads the assembly, eg a third party assembly, which allows you to make use of components written for .NET not usable in VFP directly, and the last line then creates a class instance. You don't get intellisense from it, as you get from COM classes, but that's merely a small nuisanse compared to make all the detail definitions in COM interop and even more of a pain needing to register an Assembly DLL.

The Dotnet Bridge is available as ready to use download and you can also get sources and adapt a few things by forking a github source code repository. If you need to stay VFP for several reasons and have the need to use new components only available for .NET you have a slight investment to do with that component and it's also recommended you learn enough C# or VB.NET to wrap some assembly in some proxy class you can easier use in VFP, and you might do that with an Express version or get Visual Studio from a Bizspark or Action Pack subscription. You don't need to register anything to be able to use it, that's the nices thing about it. It's already enough to keep things working while perhaps migrating whole applications or part of them and perhaps the best thing available for a smooth transition away from VFP. I would have recommended this earlier, if I had the need for it and used it earlier.

Bye, Olaf.

 

[Olaf Doschke]

Sorry, that should have been

Set Procedure To ...\wwdotnetbridge.prg && part of the download

loBridge = Createobject("wwDotNetBridge","V4")
loBridge.LoadAssembly("...Assembly.dll")
loIO = loBridge.createinstance("Assembly.Class")

 

[Dan Freeman]

And for those that don't already know this, wwDotNetBridge lives here:

http://west-wind.com/wwDotnetBridge.aspx

 

[Olaf Doschke]

Yep

I have to add, I used this for a library reading and weriting Excel files without Excel automation, even without Excel installed. It's a non visual problem, which means wwDotnetBridge doesn't qualify for UI extensions to a VFP application. For that matter you can still make use of the interop forms toolkit -

http://www.microsoft.com/en-us/download/details.aspx?id=3264.

And you can host ASP.NET inside a webbrowser control. Many ways to bridge the two worlds.

Bye, Olaf.

 

[Dan Freeman]

Yes, I have an inherited app that calls the CreateProcess() API function to run an external (C#) program. I'm considering converting it to call the necessary .NET component directly just to eliminate the need for elevated permissions for calling the external program.

But there are so many other fish to fry before I get to that.