nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What is the best practise when using ComReleaser?

D_Hornby_ddh_uni

Coding gurus,

I've got a question about best practise when using the ComReleaser object. In the first example below is some stub code showing how I would typically using ComReleaser when I'm processing within a single loop.

Using comRel As New ComReleaser()     pFeatureCursor = pFeatureClass.Update(pQueryFilter, False)   comRel.ManageLifetime(pFeatureCursor)   pFeature = pFeatureCursor.NextFeature    Do While Not pFeature Is Nothing    ' Do something  pFeatureCursor.UpdateFeature(pFeature)     pFeature = pFeatureCursor.NextFeature   Loop   pFeatureCursor.Flush() End Using

Now suppose I want to loop through another cursor whilst looping through the first cursor, so nested. Is it appropriate to have a Using statement within a using statement (1) or do you simply add the inner cursor to the comReleaser object (2). I ask as I've not seen any examples and was wondering what was the best approach when nesting cursors?

Example 1

Using comRel As New ComReleaser()     pFeatureCursor = pFeatureClass.Update(pQueryFilter, False)   comRel.ManageLifetime(pFeatureCursor)   pFeature = pFeatureCursor.NextFeature    Do While Not pFeature Is Nothing    ' Do something    Using comRel2 as New ComReleaser()       pFeatureCursor2 = pFeatureClass2.Search(pQueryFilter2, False)       comRel2.ManageLifetime(pFeatureCursor2)       ' Do something inner looping stuff  End Using    pFeatureCursor.UpdateFeature(pFeature)     pFeature = pFeatureCursor.NextFeature   Loop   pFeatureCursor.Flush() End Using

Example 2

Using comRel As New ComReleaser()     pFeatureCursor = pFeatureClass.Update(pQueryFilter, False)   comRel.ManageLifetime(pFeatureCursor)   pFeature = pFeatureCursor.NextFeature    Do While Not pFeature Is Nothing    ' Do something     pFeatureCursor2 = pFeatureClass2.Search(pQueryFilter2, False)       comRel.ManageLifetime(pFeatureCursor2)     ' Do something inner looping stuff    End Using    pFeatureCursor.UpdateFeature(pFeature)     pFeature = pFeatureCursor.NextFeature   Loop   pFeatureCursor.Flush() End Using

In example 2 pFeatureCursor2 is added to comRel on every cycle of the outer cursor loop, is that good, bad or irrelevant?

Trouver plus de publications taguées avec

Accepted answers

JasonPike

Neil and Jason,

Thank you for telling me why I should not be using comReleaser! ESRI use it in many of their code examples so this is why I have adopted it as I understood it guaranteed the release of the cursor but as Jason shows that is not always the case and using Marshal.ReleaseComObject is a more robust solution.

BUT, I can't help noticing this does not answer my question...;)

If you are using comReleaser what is the best practise when you have nested loops? Neil points out it is an ESRI class, may be one the the ESRI product developers can answer this question?

Duncan

Duncan,

Your second example is the best answer--you only need one instance of the ComReleaser.
[CORRECTION: The second example is not the best answer--see Neil's response about making sure cursors are released inside the loop.]

However, you may only end the using block once. I think the "End Using" in the inner loop that I highlighted in red was a cut and paste mistake.

Using comRel As New ComReleaser()     pFeatureCursor = pFeatureClass.Update(pQueryFilter, False)   comRel.ManageLifetime(pFeatureCursor)   pFeature = pFeatureCursor.NextFeature    Do While Not pFeature Is Nothing    ' Do something     pFeatureCursor2 = pFeatureClass2.Search(pQueryFilter2, False)       comRel.ManageLifetime(pFeatureCursor2)     ' Do something inner looping stuff     End Using    pFeatureCursor.UpdateFeature(pFeature)     pFeature = pFeatureCursor.NextFeature   Loop   pFeatureCursor.Flush() End Using

[EDIT: The paragraph below is still relevant, but Neil's response points out that releasing the COM object isn't the point--the point is having that COM object close the table it has opened, which only happens when it is released.]

The reason why you would want to add pFeatureCursor2 to the ComReleaser instance for each iteration of the inner loop is because every time you assign pFeatureCursor2 to the output of the Search() call pFeatureCursor2 is pointed to a different instance of IFeatureCursor. This means that under-the-hood a new instance of a COM object was created and returned to you and assigned to pFeatureCursor2. If you want that instance of the COM object to go away when the using block ends, you have to add it to the ComReleaser (or use the other approaches suggested by me and Neil.)

All comments

RichardFairhurst

Richard,

Did you see this thread that discovered the bug NIM087476 �??Memory leakage ESRI.ArcGIS.Geodatabase.IDataStatistics using UniqueValues property with ArcGIS 10.1 with SP1�?�

Thanks for pointing that out. I had not seeen this thread, but this explains why it worked at 10.0 and not at 10.1 SP1 (I skipped 10.1 original). I will reengineer the code to use a cursor to get unique values. Can anyone pioint me to any threads that show the most elegant techniques for doing that?

D_Hornby_ddh_uni

Richard,

I was having ArcMap crash spectacularly and it was down to the IDatastatistics object as indicated by the thread that Ken has linked to. It took a few days of headbanging a brick wall and all manner of cursing before I discovered that thread so I re-engineered the code to use a cursor to obtain unique values. It is clearly a bug introduced into 10.1

Everyone else thanks for your advice on best practise when using comReleaser (which seems to be don't use it! 😄 )

Duncan

kenbuja

Richard,

Did you see this thread that discovered the bug NIM087476 �??Memory leakage ESRI.ArcGIS.Geodatabase.IDataStatistics using UniqueValues property with ArcGIS 10.1 with SP1�?�

JasonPike

I wrote an Add-In that used a Windows form and many chained functions that create and release cursors using ReleaseComObject. Two of the functions use IDataStatistics, which takes a populated cursor as a parameter. When I was targeting ArcGIS 10.0 it all worked fine. Now with 10.1 I am getting a lot of errors about trying to access protected memory, which the MSDN help suggests is due to memory corruption, usually related to unmanaged code. The error help suggests that the memory corruption may be accumulating through many operations before triggering the error.

The failure seems to always happen on the second or third pass that is triggered by user form updates and occurs within the subroutines that have the cursor that feeds to an IDataStatistics object. The error either appears when I call the UniqueValues method of the IDataStatistics object or when I do a Search on the feature cursor before it is passed to the IDataStatistics object (only on the second or third time through the code, never the first). Its behavior can be altered by the use or lack of use of the ReleaseComObject statements for the cursor or the IDataStatistics. I have tried all of the combinations I can think of and orders of the releaser. Below is a sample of how the code is written with the two lines where the protected memory error can occur shown in Red. Any suggestions on what objects I should use the ReleaseComObject on and the order or placement of that code or how to trap these errors and issolate the real cause?
    Private Sub GetRoutesList()
        ' Set Up Query Filter for the Full Date Range of the Collision Layer respecting PDO and DUI flags
        Dim pQF As IQueryFilter = New QueryFilterClass
        pQF.WhereClause = "NOT " & fldCollisionDate & " IS NULL" & whereSeverity & whereDUI
        pQF.SubFields = fldCollisionDate & ", " & fldPrimaryRoad & ", " & fldRID & ", " & fldSeverity & ", party_sobriety_1, party_sobriety_2"

        ' Query Collisions Date Range and Street to fill Route Combobox List
        pQF.WhereClause = fldCollisionDate & " >= date '" & m_FromDate.ToString("yyyy-MM-dd HH:mm:ss") & "' AND " & fldCollisionDate & " <= date '" & m_ToDate.ToString("yyyy-MM-dd HH:mm:ss") & "' AND " & fldRID & " > ' ' AND Upper(" & fldPrimaryRoad & ") = '" & m_strPrimary & "'" & whereSeverity & whereDUI

        Dim dataStatisticsRoutes As IDataStatistics = New DataStatisticsClass
        Dim featCursorRouteList As IFeatureCursor = m_FLCollisions.Search(pQF, True)
        ' Use DataStatistics to get Unique Values
        dataStatisticsRoutes.Field = fldRID
        dataStatisticsRoutes.Cursor = featCursorRouteList
        Dim pEnum As System.Collections.IEnumerator = dataStatisticsRoutes.UniqueValues() 

        ' Fill the Combobox and suspend refresh until list is populated
        cboRoutes.BeginUpdate()
        ' Clear the Routes Combobox
        cboRoutes.Items.Clear()
        ' Reset the enumerator before trying to access its values
        pEnum.Reset()
        ' Read each Unique value and populate the Route list.  Sorting is handled by a Combobox property.
        For i As Int32 = 0 To dataStatisticsRoutes.UniqueValueCount - 1
            pEnum.MoveNext()
            cboRoutes.Items.Add(UCase(pEnum.Current()))
        Next i

        ' Release the QueryFilter
        If Not pQF Is Nothing Then
            System.Runtime.InteropServices.Marshal.ReleaseComObject(pQF)
        End If
        ' Release the dataStatistics
        If Not dataStatisticsRoutes Is Nothing Then
            System.Runtime.InteropServices.Marshal.ReleaseComObject(dataStatisticsRoutes)
        End If
        ' Release the Cursor
        If Not featCursorRouteList Is Nothing Then
            System.Runtime.InteropServices.Marshal.ReleaseComObject(featCursorRouteList)
        End If
        ' Allow the Combobox to refresh
        cboRoutes.EndUpdate()

        If cboRoutes.Items.Contains(m_strRoute) Then
            ' Set Combobox Text to the current Map Route
            cboRoutes.Text = m_strRoute
        ElseIf cboRoutes.Items.Count > 0 Then
            ' Set Combobox Text to First Route in the List
            cboRoutes.Text = cboRoutes.Items(0)
            m_strRoute = cboRoutes.Text
        End If
    End Sub
There are many other cursor calls that do not involve IDataStatistics and other Com objects from ArcGIS being created in the code. None of the cursors are embedded in each other and I have always used the ReleaseComObject call after I finish reading the cursor. These cursors have not generated errors so far, but I need to be sure they are not contributing to the problem. Any suggestions are appreciated.

Richard,

It sounds like you are having problems similar to the ones described in this thread:
http://forums.arcgis.com/threads/75186-Memory-leak-with-FeatureClass-object

I've described several debugging techniques in the thread that you might find helpful. If anyone has tried using the WinDbg or Application Verifier, they haven't posted their results. I would start with WinDbg to see what calls are in the stack with the Search() and UniqueValues() call when they crash. If it happens to be the same underlying calls, it could really shed some light on what is going wrong. If you decide to try WinDbg, don't forget to set the _NT_SYMBOL_PATH environment variable so that the ArcObject calls are fully resolved.

At least one of the developers on the other thread has filed a support ticket with ESRI, so you might want to monitor that thread as well.

If you can narrow the problem down to a small stand-alone app, zip up the entire solution, and attach it to one of your posts, I'll be happy to spend some time debugging it.

Thanks,
Jason

RichardFairhurst

I wrote an Add-In that used a Windows form and many chained functions that create and release cursors using ReleaseComObject. Two of the functions use IDataStatistics, which takes a populated cursor as a parameter. When I was targeting ArcGIS 10.0 it all worked fine. Now with 10.1 I am getting a lot of errors about trying to access protected memory, which the MSDN help suggests is due to memory corruption, usually related to unmanaged code. The error help suggests that the memory corruption may be accumulating through many operations before triggering the error.

The failure seems to always happen on the second or third pass that is triggered by user form updates and occurs within the subroutines that have the cursor that feeds to an IDataStatistics object. The error either appears when I call the UniqueValues method of the IDataStatistics object or when I do a Search on the feature cursor before it is passed to the IDataStatistics object (only on the second or third time through the code, never the first). Its behavior can be altered by the use or lack of use of the ReleaseComObject statements for the cursor or the IDataStatistics. I have tried all of the combinations I can think of and orders of the releaser. Below is a sample of how the code is written with the two lines where the protected memory error can occur shown in Red. Any suggestions on what objects I should use the ReleaseComObject on and the order or placement of that code or how to trap these errors and issolate the real cause?

    Private Sub GetRoutesList()
        ' Set Up Query Filter for the Full Date Range of the Collision Layer respecting PDO and DUI flags
        Dim pQF As IQueryFilter = New QueryFilterClass
        pQF.WhereClause = "NOT " & fldCollisionDate & " IS NULL" & whereSeverity & whereDUI
        pQF.SubFields = fldCollisionDate & ", " & fldPrimaryRoad & ", " & fldRID & ", " & fldSeverity & ", party_sobriety_1, party_sobriety_2"

        ' Query Collisions Date Range and Street to fill Route Combobox List
        pQF.WhereClause = fldCollisionDate & " >= date '" & m_FromDate.ToString("yyyy-MM-dd HH:mm:ss") & "' AND " & fldCollisionDate & " <= date '" & m_ToDate.ToString("yyyy-MM-dd HH:mm:ss") & "' AND " & fldRID & " > ' ' AND Upper(" & fldPrimaryRoad & ") = '" & m_strPrimary & "'" & whereSeverity & whereDUI

        Dim dataStatisticsRoutes As IDataStatistics = New DataStatisticsClass
        Dim featCursorRouteList As IFeatureCursor = m_FLCollisions.Search(pQF, True)
        ' Use DataStatistics to get Unique Values
        dataStatisticsRoutes.Field = fldRID
        dataStatisticsRoutes.Cursor = featCursorRouteList
        Dim pEnum As System.Collections.IEnumerator = dataStatisticsRoutes.UniqueValues() 

        ' Fill the Combobox and suspend refresh until list is populated
        cboRoutes.BeginUpdate()
        ' Clear the Routes Combobox
        cboRoutes.Items.Clear()
        ' Reset the enumerator before trying to access its values
        pEnum.Reset()
        ' Read each Unique value and populate the Route list.  Sorting is handled by a Combobox property.
        For i As Int32 = 0 To dataStatisticsRoutes.UniqueValueCount - 1
            pEnum.MoveNext()
            cboRoutes.Items.Add(UCase(pEnum.Current()))
        Next i

        ' Release the QueryFilter
        If Not pQF Is Nothing Then
            System.Runtime.InteropServices.Marshal.ReleaseComObject(pQF)
        End If
        ' Release the dataStatistics
        If Not dataStatisticsRoutes Is Nothing Then
            System.Runtime.InteropServices.Marshal.ReleaseComObject(dataStatisticsRoutes)
        End If
        ' Release the Cursor
        If Not featCursorRouteList Is Nothing Then
            System.Runtime.InteropServices.Marshal.ReleaseComObject(featCursorRouteList)
        End If
        ' Allow the Combobox to refresh
        cboRoutes.EndUpdate()

        If cboRoutes.Items.Contains(m_strRoute) Then
            ' Set Combobox Text to the current Map Route
            cboRoutes.Text = m_strRoute
        ElseIf cboRoutes.Items.Count > 0 Then
            ' Set Combobox Text to First Route in the List
            cboRoutes.Text = cboRoutes.Items(0)
            m_strRoute = cboRoutes.Text
        End If
    End Sub

There are many other cursor calls that do not involve IDataStatistics and other Com objects from ArcGIS being created in the code. None of the cursors are embedded in each other and I have always used the ReleaseComObject call after I finish reading the cursor. These cursors have not generated errors so far, but I need to be sure they are not contributing to the problem. Any suggestions are appreciated.

JasonPike

Same issue in Java. In Java, we can call garbage collection methods, but garbage collection will run when it wants according to whatever algorithm is uses.

So you're saying that your code will not wait for garbage collection, why is that? Because of the nested cursors it is running slow, or ?

Garbage collection will not run after each iteration of the loop, but each iteration of the loop opens a table. The tables need to be closed after each iteration because you can only have a limited number of tables open at one time. Garbage collection may not run until well after you leave the method that has the loop opening all the tables--it depends on things like memory pressure, generation size, etc.

LeoDonahue

In fact, you can't directly use COM objects, you use an RCW, which is managed and eligible for garbage collection, to interact and marshal data back and forth between your .NET code and COM code. The RCW will eventually be collected by the .NET GC and will release the COM object. But, the problem is that it is done at the whim of the GC and not immediately.

Same issue in Java. In Java, we can call garbage collection methods, but garbage collection will run when it wants according to whatever algorithm is uses.

In this case, the cursor needs to be released immediately because it has a table open, so we can't wait around on the GC to do its thing. Rather than waiting on the GC, you can tell the RCW to let go of the COM object by calling Marshal.ReleaseComObject on it. The RCW sticks around and waits to be collected by the GC, but it disconnects itself from the COM object it was helping you communicate with.

So you're saying that your code will not wait for garbage collection, why is that? Because of the nested cursors it is running slow, or ?

JasonPike

Is feature a managed or unmanaged object?

If it is a managed object, wouldn't the fact that the previous feature reference make it eligible for garbage collection in .NET? Otherwise, I agree, you should release it.

http://msdn.microsoft.com/en-us/library/ee787088.aspx#manipulating_unmanaged_resources

It is managed in the sense that the interfaces are referenced from a managed PIA, but the underlying implementation is in COM.

In fact, you can't directly use COM objects, you use an RCW, which is managed and eligible for garbage collection, to interact and marshal data back and forth between your .NET code and COM code. The RCW will eventually be collected by the .NET GC and will release the COM object. But, the problem is that it is done at the whim of the GC and not immediately. In this case, the cursor needs to be released immediately because it has a table open, so we can't wait around on the GC to do its thing. Rather than waiting on the GC, you can tell the RCW to let go of the COM object by calling Marshal.ReleaseComObject on it. The RCW sticks around and waits to be collected by the GC, but it disconnects itself from the COM object it was helping you communicate with.

LeoDonahue

IMO, the best practice is not to use ESRI's ComReleaser class at all. The best way to manage your COM objects is to do it yourself so that you know what's going on and have full control over it. When looping through a cursor, you should also be releasing the row/feature objects within the loop before assigning the reference to the next item in the cursor.
Dim featureCursor As IFeatureCursor = featureClass.Search(Nothing, False)
Dim feature As IFeature = featureCursor.NextFeature
Do While feature IsNot Nothing
  ' do something with the feature

  Marshal.ReleaseComObject(feature)
  feature = featureCursor.NextFeature
Loop

Marshal.ReleaseComObject(featureCursor)

Is feature a managed or unmanaged object?

If it is a managed object, wouldn't the fact that the previous feature reference make it eligible for garbage collection in .NET? Otherwise, I agree, you should release it.

http://msdn.microsoft.com/en-us/library/ee787088.aspx#manipulating_unmanaged_resources

JasonPike

The Using statement scopes the resource (the variable you declare) to the block of code between the Using and End Using statements. The purpose of the Using statement is to limit the scope of a resource within a larger block of code and to guarantee that it is disposed as soon as the End Using statement is executed. So, is it ok to nest Using statements? Yes. It's really no different than nesting loops or If/End If blocks. In your case, you're using a cursor within a loop. Each loop iteration opens a new cursor. That cursor needs to be released with each loop iteration. Each time a cursor is created, a table in the database is opened. It will not be closed until the cursor is released, so if you don't release the cursor within each loop iteration it will keep opening tables and not closing them. Eventually, you'll hit the max. number of open tables and an exception will be thrown. So, that cursor needs to be managed by its own ComReleaser object declared within the loop. If you use the ComRelease declared outside of the loop then the cursors created inside the loop will not be released until after the loop is exited.

Agreed. I have updated my post.

NeilClemmons_GISinc

The Using statement scopes the resource (the variable you declare) to the block of code between the Using and End Using statements. The purpose of the Using statement is to limit the scope of a resource within a larger block of code and to guarantee that it is disposed as soon as the End Using statement is executed. So, is it ok to nest Using statements? Yes. It's really no different than nesting loops or If/End If blocks. In your case, you're using a cursor within a loop. Each loop iteration opens a new cursor. That cursor needs to be released with each loop iteration. Each time a cursor is created, a table in the database is opened. It will not be closed until the cursor is released, so if you don't release the cursor within each loop iteration it will keep opening tables and not closing them. Eventually, you'll hit the max. number of open tables and an exception will be thrown. So, that cursor needs to be managed by its own ComReleaser object declared within the loop. If you use the ComRelease declared outside of the loop then the cursors created inside the loop will not be released until after the loop is exited.

JasonPike

Neil and Jason,

Thank you for telling me why I should not be using comReleaser! ESRI use it in many of their code examples so this is why I have adopted it as I understood it guaranteed the release of the cursor but as Jason shows that is not always the case and using Marshal.ReleaseComObject is a more robust solution.

BUT, I can't help noticing this does not answer my question...;)

If you are using comReleaser what is the best practise when you have nested loops? Neil points out it is an ESRI class, may be one the the ESRI product developers can answer this question?

Duncan

Using comRel As New ComReleaser()     pFeatureCursor = pFeatureClass.Update(pQueryFilter, False)   comRel.ManageLifetime(pFeatureCursor)   pFeature = pFeatureCursor.NextFeature    Do While Not pFeature Is Nothing    ' Do something     pFeatureCursor2 = pFeatureClass2.Search(pQueryFilter2, False)       comRel.ManageLifetime(pFeatureCursor2)     ' Do something inner looping stuff     End Using    pFeatureCursor.UpdateFeature(pFeature)     pFeature = pFeatureCursor.NextFeature   Loop   pFeatureCursor.Flush() End Using

D_Hornby_ddh_uni

Neil and Jason,

Thank you for telling me why I should not be using comReleaser! ESRI use it in many of their code examples so this is why I have adopted it as I understood it guaranteed the release of the cursor but as Jason shows that is not always the case and using Marshal.ReleaseComObject is a more robust solution.

BUT, I can't help noticing this does not answer my question...;)

If you are using comReleaser what is the best practise when you have nested loops? Neil points out it is an ESRI class, may be one the the ESRI product developers can answer this question?

Duncan

JasonPike

I second what Neil said. I would add that you probably want to release in a finally-block so that it is guaranteed to happen.

I've copied my reply from a different forum thread (http://forums.arcgis.com/threads/75186-Memory-leak-with-FeatureClass-object). It is probably way more than you were asking, but the short answer, in my opinion, is don't use ComReleaser:

COM objects do not reside in managed memory; they reside on the unmanaged heap.
COM objects are used in .NET through proxies called Runtime Callable Wrappers (RCWs) that reside on the managed heap.

COM objects use reference counting to determine when they can be deallocated. They maintain a count of references to themselves and deallocate when that counter reaches 0. When a reference to a COM object is made in .NET, a RCW is created an the COM object is incremented once and only once for that instance.

RCWs also maintain a reference count. It is separate from the underlying COM object's reference count; it tracks the number of times IUnknown is marshalled from the unmanaged heap to the managed heap. When the RCW's reference count reaches zero, it detachs itself from the COM object which causes the COM object's reference to decrement by 1.

The most important thing to remember is that for an instance of an object (e.g. a layer object containing rivers, a feature class object containing cities, etc.) there is only one, shared RCW per application domain. If that RCW is detached from the COM object, then it is detached for every managed (read: .NET) object in that application domain, including .NET code that you didn't write and have no control over. Unless you've created your own application domain, every COM object you reference in your managed code will be loaded into the Shared application domain (1 of 3 application domains created by default for each .NET process) and shared with the rest of the managed code in the process.

Microsoft provides two methods for manually releasing COM objects for cases where deterministic memory management is required and the non-deterministic .NET garbage collector cannot be relied upon:
Marshal.ReleaseComObject - decrements the RCW's reference count by 1
Marshal.FinalReleaseComObject - decrements the RCW's reference count until it reaches zero and detaches the underlying COM object

Code should only ever call ReleaseComObject as many times as it has incremented the reference count. If the RCW is released too many times, it can detach the underlying COM object before other objects that reference it are finished with it. When this happens, you get the very familiar: "COM object that has been separated from its underlying RCW cannot be used."

FinalReleaseCom object should only be used when the caller is absolutely sure no other objects are referencing the COM object--this includes managed code in the application domain that you may not have created.

As noted in other threads, ComReleaser essentially calls Marshal.FinalReleaseComObject for every object you've told it to manage. This means that you had better be sure that no other managed code in the application domain (your product, other 3rd parties, etc.) is holding a reference to the RCWs you've told it to manage. Since you can't know what other managed code might be running in the process, I think that it is unsafe to use ComReleaser--instead, COM interop should be understood and applied carefully using ReleaseComObject appropriately.

I understand that COM interop is an advanced programming topic and that the ComReleaser class was meant to lessen the pain for developers that didn't want to take the time learn it. However, this is when ComReleaser is most dangerous--when it is used by developers who don't understand its limitations and ramifications.

I've had bugs filed against products I've developed only to find out that they only occurred when another product was installed alongside it and which eventually led to the discovery that the other product had mismanaged RCWs that our product happened to be using also.

So, all that to say: ComReleaser is useful if you are absolutely sure you're passing it objects that are not referenced anywhere else in the application domain; otherwise, you risk the stability of the program when you use it.

Resources:
http://www.amazon.com/NET-COM-Comple.../dp/067232170X
http://www.amazon.com/Advanced-NET-D.../dp/0321578899
http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx
http://en.wikipedia.org/wiki/Reference_counting
http://msdn.microsoft.com/en-us/library/8bwh56xe.aspx

NeilClemmons_GISinc

IMO, the best practice is not to use ESRI's ComReleaser class at all. The best way to manage your COM objects is to do it yourself so that you know what's going on and have full control over it. When looping through a cursor, you should also be releasing the row/feature objects within the loop before assigning the reference to the next item in the cursor.

Dim featureCursor As IFeatureCursor = featureClass.Search(Nothing, False)
Dim feature As IFeature = featureCursor.NextFeature
Do While feature IsNot Nothing
  ' do something with the feature

  Marshal.ReleaseComObject(feature)
  feature = featureCursor.NextFeature
Loop

Marshal.ReleaseComObject(featureCursor)

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.