I have upgraded all my projects to VS2019 and yet I still cannot get them to talk to each other between c++ and VB. I tried to add the c++ dll in the VB project reference and I got the following error:

A reference to : 'c:\...\RungeKutta.dll' could not be added. Please make sure that the file is accessible and that it is a valid assembly or COM component.

I guess the obvious question would be, does the DLL use COM, or is it just a regular native DLL? Were you able to use the DLL from VB before upgrading the IDE?

I have never made a dll with VB before, what I have done is made a dll with C++ and I want it to work with my VB code. All my dll does is some maths. I do not know weather that means its COM or not.

[Also asked here https://www.vbforums.com/showthread.php?900902-Using-a-dll-made-by-c-for-VB&p=5615516#post5615516 ]

Yes I did, hope it is ok as it seems like these are two seperate forums with different domain names! Is one visible to the other?

Then it's just a regular native C++ DLL. You won't be able to add it as a reference in a .NET project like you're trying to do. Your options are:

1. Use P/Invoke to call into the library. P/Invoke (or Platform Invoke) is a mechanism .NET has that lets you call into native code by specifying the DLL and the function signatures in that DLL, and the runtime takes care of loading the DLL and marshalling data back and forth.

2. Write a C++/CLI DLL instead. This will generate a mixed native-managed assembly that the .NET compiler can understand link into the VB project.

3. Write a COM DLL. I've never done this, so no idea what it involves.

4. Just give up on the DLL and implement the functionality directly in VB.

Unless you have a good reason not to do it, I'd suggest going for option #4. It's probably the easiest and you're left with a project that's simpler to build. Other than that, option #1 is relatively easy; if the DLL just implements some math functions it probably has a fairly simple interface.
Option #2 is more complicated, but sometimes it's easier to grow and maintain a managed API and doing data conversion on the DLL side than to maintain a native API and doing the data conversions on the caller side. It depends on what sort of data the caller and the DLL will need to send to each other.

4 is not an option as I have already done this and it became a multi version nightmare. I need to have one version of everything so i can focus all my energy into each module seperately.

Which one is least energy in your book out of the remaining 3 options? Can you demonstrate 2? I am guessing that would be your answer.

Yes I did, hope it is ok as it seems like these are two seperate forums with different domain names! Is one visible to the other?

They are completely separate forums (and there are others). Some people browse more than one forum. It's good etiquette to indicate in a post if a question has been posted elsewhere so that potential contributors to the question can see if it has already been answered before expending time on an already-answered question.

Which one is least energy in your book out of the remaining 3 options

I'd say 1) but you don't provide any details re the .dll interfaces.

Hi the problem with doing what u say for good etiquete is that on your planet there are lots of contradictions to this, some would ban me for promoting anohter forum!

In heinsight it was better for me to play it safe!

Regards to providing details I am happy to post my code here if that is proper etiquete?

Please advise. Also is there a facility to allow me to do so? Like an upload button?

On the other forum someone suggested this:

built from a

1. C++/CLI project, or a

2. COM library. If not then you can't reference it. If it exports functions directly then you need to use

3. Platform Invoke (pinvoke), just as you do for Windows API functions.

Are any of these options similar to yours?

Yes, they're the same first three options I gave, just in a different order.

You should go with P/Invoke. You need to learn how to use it, but it really is the quickest solution.

https://learn.microsoft.com/en-us/cpp/dotnet/how-to-call-native-dlls-from-managed-code-using-pinvoke

I found this link from this metasearch:

https://duckduckgo.com/?t=ffab&q=using+p%2Finvoke&atb=v188-1&ia=web

I have never used P/Invoke, for that matter I've not really heard of it before now. My programming doesn't deal with managed code. So I can't say if any of the available links would be helpful or not.

Hi, I studied the hyperlink you sent me.

So please confirm if I understand correctly, all I have to do is wrap my dll up inside:

value class Win32 {}

And it will work yes?

No, not even close. That example is actually impressively useless, since C++/CLI code can call native functions directly, without passing through P/Invoke.

See https://www.codeproject.com/Articles/4965/Using-Platform-Invoke for a better introduction.

That article is not showing a c++ version of the code though. Can you write me a template that VB will accept when I try to reference it?

Like in the screenshot I posted in this VB thread. First priority for me is getting the dll to be accepted by VB when I try and use VB to reference it.
https://www.vbforums.com/showthread.php?900902-Using-a-dll-made-by-c-for-VB

The links George P and I provided are for using P/Invoke (option #1 above), which is done on the VB side in your case. If you want to modify the C++ code then you need to move to C++/CLI (option #2). Honestly that's too involved for me to want to bother with. If someone else wants to tackle that, feel free to do so.

But what good is that if the VB 2019 IDE wont even accept the c++ dll as a reference? All that work will be for nothing.

I have made my c++ dll files available for anyone brave enough to take a look.

https://drive.google.com/drive/folders/1d_J5Xbj7PBibm7YtKuUcxLJfa7hEuelm?usp=sharing

I got it to work with other c++ projects but failed to get the VB IDE to reference it, kept throwing back the error:

A reference to : 'c:\...\RungeKutta.dll' could not be added. Please make sure that the file is accessible and that it is a valid assembly or COM component.

Hi I just saw your message about VB side, so if I add some lines of code on VB side it will force the IDE to accept the dll reference without throwing a spat and error?

[He's also been given advice on the site mentioned above]