i'll add my test's code example to clarify the test i'm running:

 public class Test : UserControl
    {

        public Test()
        {
            Debug.WriteLine("Creating control");
            this.Controls.Add(new UltraTextEditor());
            //this.Controls.Add(new TextBox());
        }
        ~Test()
        {
            Debug.WriteLine("Test destructor called on user control");
        }
    }
    static class Program
    {
        private static void CreateTest()
        {
            Test test = new Test();
            GC.Collect(); //request GC cycle
        }
     
        [STAThread]
        static void Main()
        {
            for (int i=0; i<10; i++)
                CreateTest();

            Debug.WriteLine("Leaving test");
        }
    }

this test outputs:

Creating control
Creating control
Creating control
Creating control
Creating control
Creating control
Creating control
Creating control
Creating control
Creating control
Leaving test

if we comment out the infragistics control and uncomment the TextBox we get:

Creating control
Creating control
Creating control
Test destructor called on user control
Test destructor called on user control
Creating control
Test destructor called on user control
Creating control
Test destructor called on user control
Creating control
Test destructor called on user control
Creating control
Test destructor called on user control
Creating control
Test destructor called on user control
Creating control
Test destructor called on user control
Creating control
Leaving test

-Yossi 

Yossi,

What I believe is happening here is that the various Infragistics controls hook certain static events, such as XPThemeChanged, which will effectively root the control.  If you do not explicitly dispose this control (or the Test object that you're creating), then these static events will not get unhooked, I do not think.  However, the base Component class calls SuppressFinalize in its Dispose method, which means that you will not actually get a call to the finalizer when you dispose this control.  Therefore you will never hit your destructor.  Unless you have a very good reason though it's generally not a recommended .NET practice to use destructors and instead rely on the Dispose implementations.

-Matt 

 Hi Matt,

i'v emailed infragistics support about this, and they say the same thing -> Infragistics control hook to static events.

1. The correct way to handle garbage collection in this case would have been to use weak references in the event, as in:

 http://diditwith.net/PermaLink,guid,aacdb8ae-7baa-4423-a953-c18c1c7940ab.aspx

this will allow the objects to get collected , and their dispose method to be called implicitly by the distructor.

2. Regarding SupressFinalize, GC.SupressFinalize does not prevent the call to Dispose, but rather the redundent call to Dispose by the GC after Dispose have been called once already (the point of this function call is to prevent aggressive GC to cause rentries to the Dispose method).

As for the Control call to SupressFinalize, this call is done by the call to base.Dispose by the extending child, so in any case it's called only after the child's Dispose has executed.

3. Regarding best practices, destructors are not common and not widely used, however calling Dispose is exactly the kind of good reason you need for a destructor. it's exactly why microsoft implemented a call to Dispose in their destructor to Control.

When working in a managed environment, you expect your objects to get automatically garbage collected once you loose all references to them, this includes IDisposable objects. what i know as the best practice is to implement a destructor for all classes implementing the IDisposable interface.

as in microsoft's page on IDisposable interface : http://msdn.microsoft.com/en-us/library/system.idisposable.aspx 

 The IDisposable interface is there to allow you to release resource in case want to force the release of unmanaged resources (and allows you to release managed ones if you really want to) and dont want to wait for the GC to get to your object. 

it was not intended (and generally not used) as a means of unregistering from static events.

-Yossi 

Hi Matt,

What Yossin is saying, is absolutly correct that infragistics controls are not releasing memory. I am also facing the same problem. Matt, its not with UltraTextBox control only but

with every control. I am using UltraWebGrid control and the scanario is as followings.

 Architecture of my application is as bellow.

1. Entry page is LoginPage (.aspx)

2. having login successfully the HomePage appears. (Here we are using a MasterPage and HomePage is displayed as content page.)

3. HomePage(.aspx) is having a UltraWebGrid control

4. Master Page is having a Logout button. OnClick of Logout session is abandoned and page is redirected to LoginPage.

I profiled the application with various tools like .Net Memory Profiler and Ants Profiler after profiling the application I found that MasterPage and HomePage are not being released. When I further drilled down it, I found that MasterPage is not released since it is referenced by HomePage and HomePage is not released by ScriptManager of Infragistics.WebUI.Shared.Util namespace. Call stack is as bellow.

see attachment: Case Number: CAS-24425-CMDQQ1 in your website.

Intrestingly when I replace the UltraWebGrid with .net gridview it releases the memory properly.

I am sure the problem is with ScriptManger class of Infragistics.WebUI.Shared.Util namespace. 

Please try to resolve the issue instead of subpressing it with your unreasonable facts so that you could get the good business.

sanjeevsai,

What you've described is entirely different from what's been described earlier in this thread.  The issue mentioned earlier in this thread is unique to our Windows Forms controls, and you're using our ASP.NET controls.

Developer Support is still investigating the issue you've reported in support case CAS-24425-CMDQQ1.  This sounds like something that we might have fixed already, though it'll take some further testing to be certain that your issue is the same as the one I'm recalling.