API .NET .DLL -- unusable in VFP! 2

[Jeff-CCC]

I have a VFP 8 app written years ago for a client that used a stock broker's API to BUY/SELL/CANCEL orders. All I had to do initially to use that API was "register" their .DLL using REGSVR32.EXE, and everything showed up in VFP's Object Browser and was usable -- simple. That API has worked great for MANY years, but now that broker has discontinued all API use -- time to find another broker and API.

So, my client has me working with another broker who uses an API from a company named Rithmic. They've given me some sample .NET code, API documentation, and a file named "rapiplus.dll". I first tried what I always try, to register the "rapiplus.dll" file with REGSVR32.EXE. That didn't work (neither the 32-bit or 64-bit version) on my Windows 7 Home Premium 64-bit computer. They both gave this error:
The module "rapiplus.dll" was loaded but the entry-point DllRegisterServer was not found.
Make sure that "rapiplus.dll" is a valid DLL or OCX file and then try again.

Looking that error up and talking with Rithmic (who said they don't do COM), it seemed like it might be a .NET assembly instead. But they said they're not "Windows" folks and their .NET developer is gone, so they don't know anything about it and couldn't help me any more. So, based on what everyone on the web said, I tried using the REGASM.EXE from one of my Microsoft.NET subfolders, but none of the suggested uses worked, including:

regasm rapiplus.dll (no "types" defined)
regasm rapiplus.dll /tlb:rapiplus.tlb (it did create a type library but it wasn't usable by VFP)
regasm rapiplus.dll /regfile:regfile.reg (it wouldn't create a registry file because no "types" defined)

Do you have any ideas about how I might be able to get this .DLL to work and be able to use their API from my VFP app...maybe using "DECLARE" or something (I've tried various ways already but no luck)? I'm thinking it's just not compiled properly for COM interop, etc. and just won't be usable unless they know how to do that.

If you don't think I can get their .DLL to work in its current form, then is there a way to at least "translate" their C# code (one small sample file is attached for you to look at) into something that VFP could use to access the API stuff programmatically, instead of through a .DLL...maybe using "CREATEOBJECT" or something (I've tried various ways but no luck)?

Thank you VERY much for any advice or direction.

 

[Jeff-CCC]

FYI, I just got this response from Rithmic support:
The .NET R | API is not a COM library. If you require a COM interface, you would have to wrap the .NET R | API with COM and then use the wrapper.

I have no idea how to do this. Can anyone point me in the right direction, if you think this is THE solution?

 

[Mike Lewis]

Jeff, sorry I can't answer your direct question (other folk here will be able to help you better than I can). But are you sure you actually need the DLL? Have you considered implementing its functionality directly in VFP?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Jeff-CCC]

Mike,
I'd be fine with that, if I knew how to do it. Looking at the C# code I attached, do you know how I could "translate" that into VFP code and implement the functionality directly...maybe using "DECLARE" or "CREATEOBJECT", etc.? I've tried various methods but no luck. Any advice would be appreciated.

 

[Mike Lewis]

Jeff, I wasn't really suggesting that you translate the DLL into VFP, but rather than you forget about the DLL entirely and just write VFP code to implement the required functionality - the functionality to buy or sell stock, cancel orders, whatever. I'm assuming that you know what that functionality is. In other words, focus on the end product, not the existing code.

I appreciate that it might be more work to implement the whole thing in VFP, but at least you would have complete control over the code rather than relying on a third-party vendor.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Jeff-CCC]

Mike,
Oh, no, that's not an option. I am required to use their API to place BUY/SELL/CANCEL orders.
Again, their latest response is:
The .NET R | API is not a COM library. If you require a COM interface, you would have to wrap the .NET R | API with COM and then use the wrapper.

...and I do require a COM interface, so I'm wondering if anyone knows how to "wrap" their .DLL with COM and use the wrapper. I don't even know what this means, much less how to accomplish it! Can anyone help?

 

[Mike Lewis]

OK, point taken. I didn't really understand the issue.

It is indeed possible to call .NET from VFP. I'm not an expert in this area, but I have seen a few articles on the subject. You might try searching for Rick Stahl's wwDotnetBridge component. Doug Hennig also has at least one useful article: go to

http://doughennig.com/papers/default.html

and look for articles referring to .NET.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Just to follow up my previous post ....

I've just been reading the Doug Hennig article I mentioned. Basically, he says that wwDotNetBridge is the way to go. As far as I can see, it will do exactly what you want. It's free, easily available and well-documented. On that basis, Jeff, I'd suggest you go with that first.

Here's the URL that Doug quoted:

https://www.west-wind.com/wconnect/weblog/ShowEntry.blog?id=891&id=891

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Assemblies are not registered with regsvr32 but regasm, and as Mike points out in the last post, there is an interop library by Rick Strahl to make use of .NET Assemblies. In short, it creates the necessary wrapper in the form of a Proxy. That reduces your work of creating a .NET solution with COM interop. If you go for the manual route when the automatic generation of a proxy fails, you would have the advantage of redesigning what calls you want to make, sometimes interfaces to libraries are very atomic and you may only want to do one or two variants of things they offer to do, which means say half the parameters they offer are not changing for your case. Creating your own wrapper you can simplify things sometimes and for example let your COM class make some parameters properties, which are automatically added/forwarded.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[Jeff-CCC]

Mike,

Thanks for researching that for me and the link to wwDotNetBridge. I'll check it out.

 

[Mike Lewis]

You're welcome. And let us know how you get on with wwDotNetBridge (or whatever other solution you end up with).

By the way, I just noticed that you have only just joined the forum. Welcome.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[clipper01]

Here is an outline example of using wwDotNetBridge to connect to the Stripe API . Shows the main structure , was a tester/curiosity project ,but can confirm all works and seems similar to your case

Here is the VFP side , a 'Hello World' example , you can follow the links to the Fox2Net class , shows the main idea of connecting VFP to dotNet

Do wwDotNetBridge
Local loBridge As wwDotNetBridge
loBridge = Createobject("wwDotNetBridge","V4")
loBridge.LoadAssembly("Fox2Net.dll")
loFox = loBridge.CreateInstance("Fox2Net.Main")
? loFox.Stripe()


On the DotNet side, in this case I created a 'test' DLL called Fox2Net, this links to a test Stripe account. In your case, using Visual Studio( or get some C# guy to do it ) maybe build a small dotNet app using a reference to the RAPIPLUS assembly. Visual Studio will then show all the methods available in RAPIPLUS, and you can call them from VFP as in the example above.

** so that way you have a clean route from VFP to RAPIPLUS, no COM interop required at all

using System.ServiceModel;
using System.Collections;
using System.Data;
using System.Collections.Generic;
using System.Xml.Linq;
using System.Net.NetworkInformation;
using Stripe;
using Newtonsoft;

namespace Fox2Net
{
public class Main
{
public string Stripe ()
{

StripeConfiguration.SetApiKey("sk_test_7vJopxwB3M0ZegrRWxymdkyB");

var myCharge = new StripeChargeCreateOptions();

myCharge.CardNumber = "4000000000000341";
myCharge.CardExpirationYear = "2015";
myCharge.CardExpirationMonth = "10";
myCharge.CardName = "Joe Meatballs"; // optional
myCharge.CardCvc = "1223"; // optional
myCharge.Amount = 5153;
myCharge.Currency = "usd";

etc etc more code

 

[Koen Piller]

Jeff-CC

An other option is to buy from the original Stock broker their API, since they have meanwhile abonded use of this application you could very well purchase it at a reasonable price and continue your old programm. Could very well be faster and cheaper than to reinvent the wheel. Also consider to discuss with your client to participate in that purchase.

Koen

 

[Jeff-CCC]

Clipper01 -- thank you! That was a fantastic, straightforward example.

All, wwDotNetBridge by Rick Strahl was definitely the way to go in this case. It's working perfectly!

Thank you for that referall -- I'm SO GLAD I joined this forum. VERY HELPFUL!
I look forward to contributing myself whenever possible.

I consider this issue to be resolved and closed -- but I don't know how to "close" it on this forum. Somebody let me know what to do! haha

 

[Olaf Doschke]

This forum has no closing process. You - and not only you or the thread owner - can like "Great posts" (see at the right bottom of every post).
Threads then close by time. Really very unbureaucratic.

wwDotNetBridge is one of the interop highlights for sure, so you could also thank Rick Strahl at his site

https://west-wind.com/

this time.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

Jeff,

Although there is no mechanism for closing a thread, it is very helpful when the person who originally asked the question comes back to say that the problem has been solved and to mention which solution they adopted - as you have done in this case. So thank you for that.

Also, Olaf mentioned the "Great Post" feature. This results in a red star appearing against the post in question, and also against the thread within the main forum index. This is useful for other people who might have a similar problem, as it enables them to see the "solved" issues at a glance.

I'm glad you've found the forum. Do come back when you have more questions.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads