I have a C# Framework4.8 COM INTEROP library that takes data and puts it into a .pdf file to be saved somewhere. This involves PDFSharp, as I need to take pages out of existing .pdf files and include them in the new file - no biggie. I have a VB6 application that instantiates this COM object and supplies the data to be included in the new .pdf - here too, no biggie.

The thing Im having trouble with is the freeing up of resources, namely the PDF file that is created by PDFSharp:

        newDoc.Save(newFile);
        newDoc.Dispose();

In VB6, I cannot delete the file or overwrite, though I can still read from it (neither can I delete/rename in the explorer). I dont have this problem in my test Frmwk application. The .pdf file is bound during first debug and is not freed after ending debug - I have to close VB6 in order to lift the lock on the file. This tells me that VB6 is holding the resource indefinately, even though theoretically the VB6 COM object is NULLed and PDFSharp has disposed of it.

this is my VB6 code:

Dim path As String
Dim file As String

path = txtPath.Text
file = txtFile.Text

Dim tst As New ComDLL.Class
'Set tst = New ComDLL.Class
Dim i As Long

i = tst.GeneratePDF(path, file)
txt_OUT.Text = tst.GetErrorMessage

Set tst = Nothing

nothing special here either ...

So whats going wrong here?

EDIT: To shed a bit of light on my COM component: I have a class with two methods, as can be seen in the above VB6 code. I did not see it fit to implement a Destructor, as I get rid of all memory references in those methods - so there is nothing to get rid of, really. Was this stupid of me? Admittedly, Ive only been diving into COM for 2 weeks now...

I have a C# Framework4.8 COM INTEROP library that takes data and puts it into a .pdf file to be saved somewhere. This involves PDFSharp, as I need to take pages out of existing .pdf files and include them in the new file - no biggie. I have a VB6 application that instantiates this COM object and supplies the data to be included in the new .pdf - here too, no biggie.

The thing Im having trouble with is the freeing up of resources, namely the PDF file that is created by PDFSharp:

        newDoc.Save(newFile);
        newDoc.Dispose();

In VB6, I cannot delete the file or overwrite, though I can still read from it (neither can I delete/rename in the explorer). I dont have this problem in my test Frmwk application. The .pdf file is bound during first debug and is not freed after ending debug - I have to close VB6 in order to lift the lock on the file. This tells me that VB6 is holding the resource indefinately, even though theoretically the VB6 COM object is NULLed and PDFSharp has disposed of it.

this is my VB6 code:

Dim path As String
Dim file As String

path = txtPath.Text
file = txtFile.Text

Dim tst As New ComDLL.Class
'Set tst = New ComDLL.Class
Dim i As Long

i = tst.GeneratePDF(path, file)
txt_OUT.Text = tst.GetErrorMessage

Set tst = Nothing

nothing special here either ...

So whats going wrong here?

EDIT: To shed a bit of light on my COM component: I have a class with two methods, as can be seen in the above VB6 code. I did not see it fit to implement a Destructor, as I get rid of all memory references in those methods - so there is nothing to get rid of, really. Was this stupid of me? Admittedly, Ive only been diving into COM for 2 weeks now...

• c#
• vb6
• com-interop
• pdfsharp

Share Improve this question Follow edited Nov 19, 2024 at 14:28 TheKDude asked Nov 19, 2024 at 14:10 TheKDudeTheKDude 1922 bronze badges 2

• Temporarily disable the installed security software and try again. – Hans Passant Commented Nov 19, 2024 at 15:23
• I'd have a closer look at the PDFSharp library and see if there's a dedicated Close (the document) method. – Hel O'Ween Commented Nov 20, 2024 at 9:11

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

The issue you're encountering, where the PDF file remains locked even after disposing of the newDoc object in your C# COM Interop library, is likely due to the .NET garbage collector not immediately releasing the resources. In .NET, resource cleanup isn't deterministic; objects implementing IDisposable are cleaned up during garbage collection, which occurs at undetermined times. This behavior can lead to file locks persisting longer than expected.

To ensure that the resources are released promptly, you can explicitly force garbage collection after disposing of the newDoc object. This approach is generally discouraged in typical .NET applications due to performance considerations, but in your specific scenario involving COM Interop with VB6, it can help resolve the file locking issue.

newDoc.Save(newFile);
newDoc.Dispose();
newDoc = null;
GC.Collect();
GC.WaitForPendingFinalizers();

In production code, it's generally better to design your application to allow the garbage collector to manage memory on its own schedule. However, in scenarios like COM Interop with VB6, where deterministic resource management is crucial, this method can be appropriate.