C# DLL stays in use even after VFP object is released 1

[Rajesh Karunakaran]

Dear Team,

This may not be a complete VFP question, but I just want to see if anyone among us can help me with some clue.

I wrote a DLL in C# (.Net framework 4.7.2 targetted) which uses Json serialization. Obviously, I have made it 'Make Assembly COM-visible'. I registered this DLL with RegAsm. My Vfp object is created from the DLL. But even when the Vfp object (that was created from the DLL) released, when I try to copy the DLL file from its original folder to my Vfp trial folder, it says, '...file is in use by another process...'

Any clue on this?
I can give you more details if you have any questions.

Thanks in advance,
Rajesh

 

[Chris Miller]

That's due to thenature of .net dlls using a .net framework (as you specified yourself) and that is its runtime when you create the object, which does not terminate just because you terminated the object.
This situation is explained in more detail by Rick Strahl when he describes how his dotnet bridge works.


Chriss

 

[Chris Miller]

And just a general advice: In the C# world there always is the major difference of managed and unmanaged code/libraries/dlls. And you may need to actively dispose some things so they get unloaded.

See this earlier thread where you had the same question:
thread184-1800409

You said you almost got it. Well, I think you need to deep digger into how .NET works regarding disposing unused objects depending on whether they are partof managed part of the dotnet framework or not. Take a look on the keyword dispose.

Well, overall I recommend you ask in some c# forum or on StackExchange how objects should be disposed so a DLL assembly gets fully unloaded. There are several things to learn about this.

Chriss

 

[Chris Miller]

Well, last not least,

the one thing to take away from the old thread is that whatever keeps your C# DLL assembly to not unload is connected to the VFP process, so quitting VFP you will be able to build a new DLL or move the file. And as you said yourself in that old thread:

I would, perhaps never, need to copy a version of this DLL while the application is running.

That's a timeless truth. And in the end, you can avoid the builr DLL becoming problematic to overwrite or move, when you don't use it where it is built, but copy it to wherever your test sandbox is, involving all DLLs and VFP code you use for testing. Then you never have problems with the build process, you may still have problems overwriting the copy with a new build, but then you could give the DLL individual names.

...or restart VFP, again.

By the way, C# projects don't just allow to specify the build directory where binaries end up from compiles, you can also define post-build steps like copying a file somewhere, so you don't need to do this manually and don't forget it.

So, let's summarize:: In the worst case, you won't get unloading the DLL to work, but can define your C# build process to create a DLL in the usual bin folder, copy it from there with a version/build number in the name to somewhere else to use it. That step can never fail. In this worst case, you just accumulate a lot of DLLs in memory that don't unload.

But it's not a problem unless you use up 2GB of process memory, and in the final version, you won't ever need to overwrite or move a DLL and don't need to care about unloading, too. In the end when your VFP built EXE application quites, all DLLs it loaded will be unloaded no matter what dependencies they have. No matter if you take responsibility to manage the unmanaged parts of code in disposing and finalizing them or don't learn it.

Chriss

 

[Rajesh Karunakaran]

Chris,

Thank you for your reply and pointing me to my own earlier thread! I'd just missed to remember that.
Just went through that thread once again and able to absorb the matter regarding disposals.

However, the current situation is a bit different.
I want to return a Json from the DLL. So, I cannot in fact dispose at least the final variable holding the Json string which is being returned, isn't it? Or, maybe I can write the Json onto a file and then dispose all objects in Dll? Does that make sense?

Anyway, I am working on this.

Rajesh

 

[Chris Miller]

So, I cannot in fact dispose at least the final variable holding the Json string which is being returned, isn't it?

Why, notice a DLL not being unloaded does not mean everything related to it stays in memory. In the concept of everything is an object in C#, variables are too. But they are part of the managed framework, and releasing a variable releases its memory usage.

Imagine even the worst case it stays resident. That still makes it a variable, it doesn't turn to a constant, does it? So what are you worried about, that you can only create one JSON string?

All in all, I don't know what you implement, maybe you need to dig a little deeper into the C# world to make this better at least in this aspect you're so concerned about.

But do you have a problem using the object another time or to create a new instance? A not unloaded DLL isn't in an unhealthy state, it still works, usually. You would have to create a blocking state to make the class unusable.

Chriss

 

[Rajesh Karunakaran]

Chriss,

I wrote my answer above before seeing your last 2 posts (with quote of my own remark regarding copying dll new version).
Yes, I will discuss this in a C# forum 'StackOverflow' or similar.

As you said, Rick's article very clearly explains the exact scenarios. I will modify my DLL to have a resource disposal method also so that after getting return values from DLL, I can call the Dispose method of the DLL. That should do most of what I expect I hope.

Then, not able to copy new version of DLL when my Vfp is open (Rick explains that also beyond doubts) is not really a problem. I need that only till I finish with my debugging.

When I get everything as expected, I will come back here with a note on what I did.

Thank you Chriss!

Rajesh