Unmanaged ArcObjects and C#/.NET Class Design Patterns

Question

I am currently writing a set of batch processing jobs using ArcObjects in C#.NET. I noticed that a lot of ESRI examples pile the code into one static class with each member declared inside each method scope.

I am considering using either a factory pattern or a singleton pattern for processing features. The intent is to wrap the unmanaged interfaces in instance classes to compartmentalize the code a bit and help with re-usability. These classes implement the IDisposable interface to help make sure everything is properly cleaned up after use.

Considering what you know about COM objects, could you please let me know if the following class looks effective? Is my expectation of reusability reasonable considering how COM works? I.e., If I encapsulate a COM member, will it provide the same benefit as a manged type, or is this adding unnecessary overhead? As far as I know, the only managed type I am using is the Geoprocessor class, IFeatureClass is unmanaged.

public class FeatureProcessing : ProcessBase, IDisposable
{
    #region Fields

    private IFeatureClass _FeatureClassObj;

    private ITrackCancel2 _GPTrackCancel;

    private Geoprocessor _GeoProcessor;

    private bool _IsRunning = false;

    #endregion Fields

    #region Properties

    public IFeatureClass FeatureClassObj
    {
        get
        {
            return _FeatureClassObj;
        }
        private set
        {
            _FeatureClassObj = value;
        }
    }

    public bool IsRunning
    {
        get
        {
            return _IsRunning;
        }
    }

    #endregion Properties

    #region Constructor

    public FeatureProcessing(IFeatureClass feature)
    {
        _FeatureClassObj = feature;
    }

    #endregion Constructor

    #region Methods

    public void Simplify(int footTollerance = 5, SimplifyAlgorithmTypes algorythmType = SimplifyAlgorithmTypes.POINT_REMOVE)
    {
        //FeatureClass tmpFeatureClass = new FeatureClass(null);
        ESRI.ArcGIS.CartographyTools.SimplifyLine lineSimplify = new ESRI.ArcGIS.CartographyTools.SimplifyLine();
        lineSimplify.in_features = _FeatureClassObj;
        lineSimplify.out_feature_class = $"{_FeatureClassObj.AliasName}_Simplified";
        lineSimplify.tolerance = footTollerance;
        lineSimplify.algorithm = algorythmType.ToString();
        RunGeoprocessingOperation(lineSimplify);
    }


    private void RunGeoprocessingOperation(IGPProcess gpProc)
    {
        _GeoProcessor = new Geoprocessor();
        _GeoProcessor.OverwriteOutput = true;
        _GeoProcessor.ToolExecuting += Gp_ToolExecuting;
        _GeoProcessor.ToolExecuted += Gp_ToolExecuted;
        _GeoProcessor.ProgressChanged += Gp_ProgressChanged;
        IGeoProcessorResult2 gpResult = _GeoProcessor.Execute(gpProc, _GPTrackCancel) as
            IGeoProcessorResult2;
    }

    private void Gp_ToolExecuting(object sender, ToolExecutingEventArgs e)
    {
        if (e.GPResult == null) return;
        _IsRunning = true;
        IGeoProcessorResult2 result = e.GPResult as IGeoProcessorResult2;
        base.RaiseProcessEvent(ProcessEventTypes.INFO, $"GPTool: {result.Process.ToolName} started");
    }

    private void Gp_ToolExecuted(object sender, ToolExecutedEventArgs e)
    {
        _IsRunning = false;
    }

    private void Gp_ProgressChanged(object sender, ProgressChangedEventArgs e)
    {
        base.RaiseProcessEvent(ProcessEventTypes.INFO, e.Message);
    }

    public void CancelRunningTask()
    {
        if (_IsRunning != false && _GPTrackCancel != null)
        {
            _GPTrackCancel.Cancel();
            _IsRunning = false;
        }
    }

    public void Dispose()
    {
        CancelRunningTask();
        ReleaseCOMObj();
    }

    private void ReleaseCOMObj()
    {
        int refsLeft = 0;
        if (_FeatureClassObj != null)
        {
            do { refsLeft = Marshal.ReleaseComObject(_FeatureClassObj); }
            while (refsLeft > 0);
        }
    }
    #endregion Methods
}

Answer 1

There are very few objects that ESRI suggests you need to explicitly release. See: How to release COM references

In general, aside from those objects ESRI explicitly says should be released, you don't really need to call Marshal.ReleaseComObject, and in fact doing so can cause serious issues.

The objects that people generally release, in the way you are asking about, are cursors and any enumerator that may be backed by a cursor. This is done since cursors are:

• Generally a finite resource, and if created in a loop the GC might not be able to release out of scope objects and their cursors as fast as the loop creates them. Eventually the loop may not be able to create new cursors and an exception will be thrown. Once the code continues the GC will run and the out of scope cursors will be released, but from a UX pov you've already pissed off the user.
• Well understood to never be cached internally by ArcObjects. The function that creates the cursor knows it has full ownership of the cursor.

The risk in just calling Marshal.FinalReleaseComObject, or looping on Marshal.ReleaseComObject, is that other code may still have a reference to the wrapped COM object. That code could be yours, other 3rd party dll's, or internal (cached) in ArcObjects.

So, general rules:

1. Don't use Marshal.*ReleaseComObject unless you need to.
2. If creating reusable classes (like you want to do) then start by only creating them for cursors and some enumerators.
3. Never call Marshal.FinalReleaseComObject or loop on Marshal.ReleaseComObject. If you create once then release once. If you want to go nuts and create release wrappers for everything then at least follow this rule.

In your example there is a (good ?) chance the IFeatureClass you are forcably releasing is cached/referenced somewhere else. Your code would nuke it and result in "The RCW is separated from its underlying object" type errors when the other code tried to use its reference to the IFeatureClass.

Also read: Marshal.ReleaseComObject Considered Dangerous

Answer 2

At a cursory glance this looks like it will work well.

I would change your releaseCOMObj and make it available more program wide:

public static void ReleaseCOMObj(object o)
{
    if (o != null && System.Runtime.InteropServices.Marshal.IsComObject(o))
        Marshal.FinalReleaseComObject(o);
        //or Marshal.ReleaseComObject(o) 
}

Also get Simplify() out of there.