C# DLL Declare Function

[D-Ward]

Hi,

I need to access a C# DLL, but can not get it to work. I have access to the C# source code and the author, having been trying for a couple of days and just cannot get it to work. Have tried compiling it both ways, so you use DECLARE (preferred method) or as a COM object so you have to register it and use CREATEOBJECT().

So we have just created a very simple DLL from an example online, DECLARE the functions in VFP, which show up when you DISPLAY STATUS, but when you call the function you get the 'Cannot find entry point' error. Have been googling it and can not see why it is not working.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Calculation
{
    publc class calculate
    {
        //Method used for Addition
        public int Add(int a,int b)
        {
            return a + b;
        }
        //Method used for Substraction
        public int Sub(int a,int b)
        {
            return a - b;
        }
    }
}

Have checked it is being compiled as a 32 bit DLL, have checked naming as know they are case sensitive. Have used DECLARE before for Win DLL's without an issue, but will not work with this :-(

 

[mJindrova]

It's a class in c# in .NET DLL, not it classic DLL with flat fuctions. Use https://github.com/RickStrahl/wwDotnetBridge

 

[Chris Miller]

What you could do in C# is the other thing you already mentioned: COM. It still is a bit more complex than just the usual regsvr32 registration of the C# DLL, you need COM visible classes and can then use them as OLE objects in VFP.

See https://www.codemag.com/article/0404072/COM-Interop-Making-.NET-and-VFP-Talk-to-Each-Other and concnetrate on the part titled "Calling .NET Components from VFP".

 

[D-Ward]

Thanks for the reply.

Sounds a bit like a sledge hammer to crack a walnut as the functions are purely math based. Had the option of re-writing the functions in VFP but wanted them in a single location as are security related. Will convert to C++ and create an unmanaged DLL to use in VFP.

 

[D-Ward]

Hi Chriss,

My reply crossed over with yours, thanks for the link, will take a look.

Darren

 

[Chris Miller]

AS VFP is programmed in C/C++ and needs the msvcr71.dll runtime, it's always cracking a nut with a hammer to go with anything else, because the foreign compenent, be it VB, C# or any other language, will need its own runtime.

C# is not just simply a newer C++, you know the C++ programming language evolves on its own roadmap and is currently at version 14 already (from MS perspective and C++20 from the C++ standrd versioning perspective. What still makes some components easier to use than others is the availability of runtimes within Windows.

I think you'll also have a harder time to get hands on an older MS Visual C++ IDE to create DLLs for the msvcr71.dll VFP uses anyway, and you don't really need to. I think even then you just spare a file, if at all, but the DLL will still spawn an own usage of the same runtime.

The COM idea is to have interoperability across different programming languages, so I wouldn't put it into the same level of impedance mismatch as is any other more complex interoperability based on shared memory, for example or command line execution.

Besides, you'll have a harder time to rewrite C# code to C++ as this isn't just next level C language, it's closer to JAVA than to C++. And then, either COM interop or the dotNET Bridge are not a strange construct at all, it's quite natural interop between two programming worlds.

Of course the Add/Sub example was just a playground for testing. If you don't have any essential code worth using as is - even merely for the reason to guarantee exact same results from function/method calls, then why not go the COM interop path? If you need to translate C# to C++ to use a classic DLL function library, then you don't profit from that aspect of using the exact same component and code anyway.

 

[Chris Miller]

One last, simple, but likely the most important aspect: If the C# developer of the components you want to use or are asked to use is wanting the least changes to allow interop with VFP, then use the dotNet Bridge mJindrova pointed out. It allows usage of assemblies, the "Features at a glance" listed in the Github repository mention "Access most .NET Components directly even those not marked [ComVisible]" as first point. It acts, as the name say, as a bridge, that doesn't require to make C# components com visible to use them from VFP. It has pros and cons, but the most obvious plus is no need to change the C# codebase at all.