FoxPro and .NET Interop
"Resources" not surviving across the COM boundry
Gravatar is a globally recognized avatar based on your email address. "Resources" not surviving across the COM boundry
  Paul
  All
  Jan 30, 2018 @ 01:36pm

Hi Rick,

I'm hoping you can shed some light on a problem I'm having, although it involves a 3rd party assembly whose internal behaviour is a mystery, so I'm looking for any general tips you may have.

The problem can be expressed as follows :

  1. I have created a .NET wrapper assembly with classes that interface with a 3rd party API (another .NET assembly)
  2. an object is created in VFP from my wrapper class via wwDotNetBridge.CreateInstance() - all good
  3. run a method on that object which "logs in" in the API, via one of the API's static methods - this creates an ADO connection to a database and no doubt does lots of other things
  4. all good within the .NET method, the login succeeds
  5. run another method on the object which relies on the object being "logged in", in other words the internal resources of the API are set up for a connected database etc
  6. I now discover that the object is no longer "logged in" and errors occur

I see this happening when debugging in both VFP and Visual Studio, which is attached to the VFP process.
After step 4, in which the login succeeds, control is returned to the VFP object and at that point, when we cross back over the COM boundry to VFP, the 3rd party API seems to decide that it is time to release whatever "resources" it had open.
If I test this scenario using purely .NET, so calling my wrapper classes from a .NET app instead of using VFP and COM, everything works fine and the internal "resources" persist until I later "log out" of the API.

The next test I will do is to call the API's static login method directly from VFP using wwDotNetBridge.InvokeStaticMethod(), but in the meantime maybe you or someone else has an idea?

Thanks.
Paul

Gravatar is a globally recognized avatar based on your email address. re: "Resources" not surviving across the COM boundry
  Rick Strahl
  Paul
  Jan 31, 2018 @ 01:44pm

When you say logged in, are you talking about a SQL Connection via ADO.NET?

If so, the connection is held alive by an object reference of the connection object or not calling the .Close() method on the connection. As soon as the connection is released the connection is closed.

Also some SqlCommands - like reading a data reader - automatically close connections after they are done, unless you explicitly specify otherwise.

You can always check the Connection Object's ConnectionState property and call .Open() to re-open if it is closed.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: "Resources" not surviving across the COM boundry
  Paul
  Rick Strahl
  Jan 31, 2018 @ 02:05pm

By "log in" I mean, in general terms, that the API authenticates with the 3rd party database, does other stuff with the database via ADO and probably collects and stores all sorts of metadata to be used for the lifetime of the "login" session.
The details are not exposed to me - all of this is inside a 3rd party assembly, without any source code.

Unfortunately the developers of the API have not yet been forthcoming when I asked them the same question.

My general question, which is vague I know, is whether there are any concepts that would point to why the "stuff" being set up by this assembly is not surviving the trip back to VFP, via COM, from .NET.
The symptoms all point to the API/assembly effectively "logging out" and releasing all internal resources as soon as I finish calling their login process and return to VFP. Noticeably, this does not happen if I call their login process and perform other tasks after that purely in .NET - only the inclusion of COM produces this behaviour.

Paul

Gravatar is a globally recognized avatar based on your email address. re: "Resources" not surviving across the COM boundry
  Rick Strahl
  Paul
  Jan 31, 2018 @ 03:25pm

If you are releasing the object the connection is probably lost. Most likely you just need to hang on to the object instance for the duration of the requests that you plan to run.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: "Resources" not surviving across the COM boundry
  Paul
  Rick Strahl
  Jan 31, 2018 @ 03:51pm

The trouble is that the VFP object is being kept alive and in fact testing shows that the API's "resources" (whatever they may be) no longer exist on the very next call from VFP, on the very next line of code, to anything on that object.
I suspect it is something to do with the static nature of the method in the .NET API that performs the "login"; since that code isn't directly attached to my object as such, something is dying when control passes back to VFP.

Oh well, I'll just have to refactor my code to perform all of its tasks via just one call to a .NET method (which "logs in", performs the tasks and then "logs out"), thereby removing the to-and-fro across COM.

Thanks for your time. Paul

Gravatar is a globally recognized avatar based on your email address. re: "Resources" not surviving across the COM boundry
  Rick Strahl
  Paul
  Jan 31, 2018 @ 04:19pm

I'm not sure why that wouldn't work. If the API is static it has to be caching the data in the AppDomain which means it's effectively global data that doesn't go away.

Other than that I think that there must be difference to the way the .NET code runs and how you are calling it from FoxPro. The code you execute from FoxPro is the same as .NET executes as long as you keep the references and dependencies alive in your code. My guess is you're inadvertantly releasing something that should be kept alive.

+++ Rick ---

© 1996-2024