locked
DSOleFile - CustomProperty not releasing file RRS feed

  • Question

  • The following code runs fine in Vb.Net.

    If the lines using the DSOleFile.CustomProperty are uncommented and ran, an exception:

    The process cannot access the file because it is being used by another process

    is thrown when the file rename is attempted.

    I am new to .Net. So I have the following questions besides the exception.

    Am I using the Marshal.ReleaseComObject properly?

    Should I set the object to Nothing after using Marshal.ReleaseComObject?

    Should I use a System.GC.Collect()?

    Thanks,

    Tim

     

    Sub Main()

    Dim FName As String = "\\Dcpp318d\ProcApps\ApprovalPrint\ReadyForUpload\01027907.DOC"

    My.Computer.FileSystem.RenameFile(FName, System.IO.Path.GetFileName(FName).ToString & "a")

    My.Computer.FileSystem.RenameFile(FName & "a", System.IO.Path.GetFileName(FName).ToString)

    Dim oFilePropReader As DSOleFile.PropertyReader = New DSOleFile.PropertyReader

    Dim oDocProp As DSOleFile.DocumentProperties = oFilePropReader.GetDocumentProperties(FName)

    With oDocProp

    Debug.Print(.Name())

    End With

     

    'Dim cp As DSOleFile.CustomProperty = oDocProp.CustomProperties(1)

    'For Each cp In oDocProp.CustomProperties

    'Debug.Print(cp.Name.ToString & ": " & cp.Value.ToString)

    'Next

    'System.Runtime.InteropServices.Marshal.ReleaseComObject(cp)

    'cp = Nothing

     

    System.Runtime.InteropServices.Marshal.ReleaseComObject(oDocProp)

    System.Runtime.InteropServices.Marshal.ReleaseComObject(oFilePropReader)

    oDocProp = Nothing

    oFilePropReader = Nothing

    My.Computer.FileSystem.RenameFile(FName, System.IO.Path.GetFileName(FName).ToString & "a")

    My.Computer.FileSystem.RenameFile(FName & "a", System.IO.Path.GetFileName(FName).ToString)

    'Exception: The process cannot access the file because it is being used by another process.

    End Sub

    Thursday, January 3, 2008 5:22 PM

Answers

  • Tim_Shaf,

     

    DOSleFile is the unmanaged COM component that can help you to manipulate the Office documents. In order to use the COM components correctly, you need to register the DLL with RegSvr32.exe correctly and add the reference for the component in your VB.NET application.

     

    1. I would like to provide you the Microsoft sample project that can be used from scripting languages to read the OLE document properties of Microsoft Office files using the OLE IPropertyStorage interface:

     

    Microsoft Developer Support OLE File Property Reader 2.1 Sample (KB 224351)

     

    2. Marshal.ReleaseComObject method decrements the reference count of the supplied runtime callable wrapper. I suggest you to read the following blog on the dangerous to use this method to help you understand this issue:

     

    Discussion of Marshal.ReleaseComObject and its dangers

     

    3. When you reference a COM object, you actually maintain a reference to an RCW. The RCW holds an internal pointer to the COM object's IUnknown interface. During finalization of the RCW, the CLR finalizer thread calls the RCW's finalizer, which in turn calls IUnknown::Release to decrement the COM object's reference count. When the reference count reaches zero, the COM object is released from the memory.

     

    .NET memory management is nondeterministic, which can cause problems when you need to deterministically release COM objects in server applications, such as ASP.NET applications. You can use Marshal.ReleaseComObject to help solve this problem.

     

    Please take a look at the following article on How ReleaseComObject Works:

     

    Improving Interop Performance

     

    4. Addintion information on this topic that can help you further:

     

    .NET Interop: Get Ready for Microsoft .NET by Using Wrappers to Interact with COM-based Applications

     

    Hope that can provide you the help on understanding this kind of problems.

    Tuesday, January 8, 2008 6:47 AM
  • Tim_shaf,

     

    Thanks for the reply. I agree with that ReleaseComObject is not necessary on your project. According to your further question on using dsofile.dll version 1.1.0.1 in your VB 6 application, I would like to suggest you to try to test the application whether it will broke with the old dsofile and other steps.

     

    This forum supports Visual Basic.NET (7, 7.1, 8, ...) issues only, so, your Visual Basic 6 question is an off-topic here and this isn't the best place to ask it, here is a list of forums, newsgroups, resources and sites, to get an answer about your question :

     

    Thanks again for your question.

    Thursday, January 10, 2008 8:28 AM
  • Bruno.Yu,

     

    My initial testing indicates that both versions of the dsofile.dll can be

    registered and used.

     

    Thank you very much for your help.

    Thursday, January 17, 2008 8:11 PM

All replies

  • Tim_Shaf,

     

    DOSleFile is the unmanaged COM component that can help you to manipulate the Office documents. In order to use the COM components correctly, you need to register the DLL with RegSvr32.exe correctly and add the reference for the component in your VB.NET application.

     

    1. I would like to provide you the Microsoft sample project that can be used from scripting languages to read the OLE document properties of Microsoft Office files using the OLE IPropertyStorage interface:

     

    Microsoft Developer Support OLE File Property Reader 2.1 Sample (KB 224351)

     

    2. Marshal.ReleaseComObject method decrements the reference count of the supplied runtime callable wrapper. I suggest you to read the following blog on the dangerous to use this method to help you understand this issue:

     

    Discussion of Marshal.ReleaseComObject and its dangers

     

    3. When you reference a COM object, you actually maintain a reference to an RCW. The RCW holds an internal pointer to the COM object's IUnknown interface. During finalization of the RCW, the CLR finalizer thread calls the RCW's finalizer, which in turn calls IUnknown::Release to decrement the COM object's reference count. When the reference count reaches zero, the COM object is released from the memory.

     

    .NET memory management is nondeterministic, which can cause problems when you need to deterministically release COM objects in server applications, such as ASP.NET applications. You can use Marshal.ReleaseComObject to help solve this problem.

     

    Please take a look at the following article on How ReleaseComObject Works:

     

    Improving Interop Performance

     

    4. Addintion information on this topic that can help you further:

     

    .NET Interop: Get Ready for Microsoft .NET by Using Wrappers to Interact with COM-based Applications

     

    Hope that can provide you the help on understanding this kind of problems.

    Tuesday, January 8, 2008 6:47 AM
  • Bruno.Yu,

     

    Thanks for the reply. This information really helps. I am too green to follow the info

    regarding the ReleaseComObject, but with the information about the OLE File Property

    Reader 2.1, it looks like I will be able to accomplish my needs without needing the

    ReleaseComObject.

     

    I was using version 1.1.0.1 of the dsofile.dll and that appears to have been my problem. 

    Now I have another potential problem:

     

    1. I have several VB6 applications running on quite a few desktops on our network that

    are using the version 1.1.0.1 dsofile.dll.

    2. The interface appears to have changed from the version 1.1.0.1 dsofile.dll to the 2.1.2841.0

    version of the dsofile.dll.

    3. When I roll out my new application to users that have VB6 applications that use the old

    dsofile.dll, won't these applications be broken?

    4. If True, do you have any suggestions?

     

    Thanks for the help.

     

    Wednesday, January 9, 2008 4:07 PM
  • Tim_shaf,

     

    Thanks for the reply. I agree with that ReleaseComObject is not necessary on your project. According to your further question on using dsofile.dll version 1.1.0.1 in your VB 6 application, I would like to suggest you to try to test the application whether it will broke with the old dsofile and other steps.

     

    This forum supports Visual Basic.NET (7, 7.1, 8, ...) issues only, so, your Visual Basic 6 question is an off-topic here and this isn't the best place to ask it, here is a list of forums, newsgroups, resources and sites, to get an answer about your question :

     

    Thanks again for your question.

    Thursday, January 10, 2008 8:28 AM
  • Bruno.Yu,

     

    My initial testing indicates that both versions of the dsofile.dll can be

    registered and used.

     

    Thank you very much for your help.

    Thursday, January 17, 2008 8:11 PM