×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

DotNet DLL object not getting released, perhaps

DotNet DLL object not getting released, perhaps

DotNet DLL object not getting released, perhaps

(OP)
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

RE: DotNet DLL object not getting released, perhaps

Hi Rajesh,

just try:

CODE -->

obj.Quit
obj = null    && <= really needed ??? try omitting !!!
RELEASE obj 

Regards, Stefan

RE: DotNet DLL object not getting released, perhaps

(OP)
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

RE: DotNet DLL object not getting released, perhaps

Quote:

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:

CODE -->

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

RE: DotNet DLL object not getting released, perhaps

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/vfpDotNetInter...

Quote (Rick Strahl)

.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

Quote (myself)

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

RE: DotNet DLL object not getting released, perhaps

Hi Rajesh,

You didn't confuse me smile

but: just when creating a Word-Instance

CODE -->

obj = CREATEOBJECT( "Word.Application" ) 

You must call

CODE -->

obj.Quit 

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

verifiable with Task Manager or Process Explorer

Regards, Stefan

RE: DotNet DLL object not getting released, perhaps

Quote:

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

RE: DotNet DLL object not getting released, perhaps

(OP)
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

RE: DotNet DLL object not getting released, perhaps

Not sure about this, but you could also try CLEAR DLLS.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: DotNet DLL object not getting released, perhaps

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

RE: DotNet DLL object not getting released, perhaps

(OP)
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

RE: DotNet DLL object not getting released, perhaps

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

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: DotNet DLL object not getting released, perhaps

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/vfpDotNetInter....

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.

Quote (Rick Strahl)

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

RE: DotNet DLL object not getting released, perhaps

(OP)
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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close