Microsoft .NET Framework applications explicitly manage references to remote COM objects

Description

Working with ArcGIS Server in a Microsoft .NET Framework application often requires implementing a number of programming patterns to manage remote COM object resources. In general, three techniques enable the release of a COM object and its reference in .NET:

1. Use the IDisposable pattern to explicitly release server contexts by implementing a custom ESRI class, WebObject, in a using block (C#) or try/catch block (VB).
2. Periodically invoke garbage collection throughout an application's lifetime.
3. Call ManageLifetime() for every COM object instance created in an application.

All patterns work, but require a significant amount of additional code and degrade application performance.

Additional information on these patterns and their implementation is provided here: Managing ArcGIS Server Resources

Cause

The Microsoft .NET Framework 1.1 garbage collection mechanism has a bug that affects creating and managing references to COM objects on a remote server (DCOM). Since ArcGIS Server is highly dependent on DCOM communication, this bug affects all aspects of using fine-grained ArcObjects in ArcGIS Server with the Microsoft .NET Framework. It causes COM objects that are not explicitly released with calls to Marshal.ReleaseComObject() or Garbage Collection to accumulate on the DCOM server. The server periodically tries to ping clients to see whether the COM objects should be kept alive. As the number of unreleased objects increases, the pings take longer and longer and eventually incapacitate the server.

Solution or Workaround