DotNet DLL object not getting released, perhaps 1

[Rajesh Karunakaran]

Dear Team!

I am not sure if I can put up this question here as it's not completely VFP.

I wrote a DLL in DotNet to access a web API. I registered that using regasm.
I create an object using CREATEOBJECT and able to call the API. I am getting the response as well.
After that I clear that object with 'obj = null' and then 'RELEASE obj'.

However, then when I try to copy a new version of the DLL from my DotNet folder to my VFP application folder,
it says that it cannot copy as the folder or file is still in use. This means, I believe, that one or more
of the resources have not been cleared yet, somehow.

I can assume that the problem could be in my DotNet program or in VFP.
As far as I know, in VFP, setting the obj to null and then RELEASEing it are enough for a DLL object
to be cleared from memory. Or, is there something more to it?

Rajesh

 

[StefanFoerner]

Hi Rajesh,

just try:

[b]obj.Quit[/b]
obj = null    && <= really needed ??? try omitting !!!
RELEASE obj

Regards, Stefan

 

[Rajesh Karunakaran]

Dear Stefan,

I think I made you confused. The 'obj' I refer is a part of my VFP program, not in DotNet.
In VFP, do we have a 'Quit' method for an object created with CREATEOBJECT ?

Rajesh

 

[Mike Lewis]

In VFP, do we have a 'Quit' method for an object created with CREATEOBJECT ?

No. There is no native Quit method in VFP (there is a QUIT command, but that is something quite different). A programmer can create a custom Quit method in a class, but there is no reason to suppose that you have done that in this case. I don't understand why Stefan suggested it.

When I create an object via CREATEOBJECT(), I get rid of it like this:

IF TYPE("oMyObject") = "O"
  RELEASE oMyObject
ENDIF

But that has got nothing to do with the error you are seeing. That error appears to be because the file is open in some other process, which has got nothing to do with releasing VFP objects.

Does the error occur even after you close VFP?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

What methods you have depends on the object you create, and what the objects use internally within the Dotnet language, too.

So it's not clear what you can do to release all that's hindering the DLL to be overwritten.

Rick Strahl has mentioned that here:

https://west-wind.com/presentations/vfpDotNetInterop/DotNetFromVFP.html

.Net loads the .Net runtime into a process – in our case VFP or your custom VFP application. Inside of that process it creates an AppDomain to host your .Net component. AppDomains cannot be unloaded until the .Net runtime shuts down and .Net components loaded via COM do not automatically shut down the .Net runtime. This means that .Net leaves your .Net assembly loaded in memory until you shut down VFP or your app.

And when you use the Dotnet Bridge that means you have not only to release an assembly instance you created with LoadAssembly but the Dotnet bridge main object itself, before the Dotnet framework runtime unloads. I mentioned that already, you may have misread that as you only need to release your object.

Within I said

the Unload method of the wwDotNetBridge class unloads the CLR runtime. And as the comment says you don't call that, it's an event that runs, when you set the dotnetbridge object to .NULL.

That means the dotnetbridge object, not only any object you created with the dotnetbridge, but the bridge itself. When you use the dotnetbrodge at some point you do run an initialization telling which fraemwork version you want to use: loBridge = CreateObject("wwDotNetBridge","V4") As long as that loBriodge object exists any assembly you used through it will be kept in the AppDomain Rick Strahl mentioned in the article about using Dotnet via COM from VFP. Which also includes cleanup within the Dotnet world with Dispose where it applies.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[StefanFoerner]

Hi Rajesh,

You didn't confuse me

but: just when creating a Word-Instance

obj = CREATEOBJECT( "Word.Application" )

You must call

obj.Quit

otherwise a Word-Instance remains unvisible in memory (RAM) !!!

verifiable with Task Manager or Process Explorer

Regards, Stefan

 

[Mike Lewis]

just when creating a Word-Instance
obj = CREATEOBJECT( "Word.Application" )

You must call
obj.Quit

Ah, yes, but that's because the authors of Word made an explicit decision to give their object a Quit method. That doesn't alter the point about the absence native Quit methods in VFP (in fact it confirms it).

Mike






__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Mike / Olaf,

Basically, I am accessing a web API.

For this, I am not using wwDotNetBridge. Instead I wrote a DotNet DLL mostly with sample code provided by the API developer. That works great!
So, I copy that DLL (from DotNet bin/debug folder) onto my VFP trial run folder.
In that VFP folder, I open VFP IDE and I create an object of the class in the DLL. Here things are fine.
I do check some methods in the DLL.
Then, I release the object variable through "... = null" and then 'RELEASE <obj var name>".
Now, If I try to copy the DLL file again from DotNet folder to this VFP folder, it wouldn't allow!
But, if I quit from that instance of VFP (as Mike asked), then I can copy.
I tried commands like 'CLEAR RESOURCES' etc but without solution for the problem.

In fact, this copying issue is actually not a serious requirement in the production enviro.
But, when I saw this problem, I was wondering if that could be an issue later and hence want to know the cause.

Thanks
Rajesh

 

[Mike Lewis]

Not sure about this, but you could also try [tt]CLEAR DLLS[/tt].

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

And why is this a problem? Presumably, you only need to copy the DLL to your development environment during the course of development. Once the system is in production, will you have any reason to do that?

Really, this is not a VFP issue. It is not unusual for Windows to decline to copy (or rename or delete) a file that is in use by an application. You could argue that it's a VFP bug, because VFP should have released the DLL at that point. But quitting the application in question is a fairly normal solution, I would have thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Mike,

I have registered the DLL using 'regasm' and in vfp program I just do "... = createobject('xxxxx.nnnn').
I am not using the DECLARE command for the DLL.
So, I think, there is nothing to be cleared through 'CLEAR DLLS'.
However, I will certainly check if that command has any effect.

Thank
Rajesh

 

[Mike Lewis]

Rajesh, you are probably right. CLEAR DLLS is used when you register a DLL via [tt]DECLARE ... IN ...[/tt]

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

OLE instances you create via COM by their OLE server name xxxxx.nnnn cause an EXE or DLL to be loaded and the runtime necessary to run that. So I just point back to

https://west-wind.com/presentations/vfpDotNetInterop/DotNetFromVFP.html.

As you first copy the DLL to your folder and register it there, you just shift the problem Rick Strahl described having when compiling to having it when you want to replace the DLL. The DLL you use will be used by a runtime process and so get used to quitting VFP for letting that additional runtime release. You don#t have a handle on it.

This means you have to be careful about releasing resources from your .Net COM components wisely as part of COM method calls or by providing explicit COM calls.

With this Rick Strahl says the problem can only be solved within the dotnet code, which would need to not just rely on garbage collection doing its work but force that. So whenever you release the main object you use the release of that in the dotnet process space quits all used resources and deallocates all RAM, so the runtime can also quit and the DLL file is closed and can be replaced.

I second Mike, it's not a big thing, you just need to quit and restart VFP. Does that cause a long turnaround time to you? If so, you may start the Task Pane with VFP, untick that and VFP starts in under 2 seconds.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Olaf / Mike,

First of all, dear Mike, I never wanted to project this as a VFP problem. I was just wondering, as a normal case, even after I release the object, why I am not able to copy the DLL. But, after going through texts suggested by Olaf and a few other sources as well, I almost got the idea.

Also, yes, both of you're correct. I would, perhaps never, need to copy a version of this DLL while the application is running.
I have already expressed this my text above.

Anyway, going through the team's thoughts on this was great!

Thank you everyone for your time!
Rajesh