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 

You could have developer support submit a bug regarding this issue, but I can't say whether or not it will be implemented as such.

-Matt 

I am running into this issue as well.  I am using 2008.3 with the latest hotfix.  Is this schedule to be fixed soon?

What is the status of this issue?  Is there any workaround for this issue?  Is there an interface we can get at to manually unhook the static event handlers holding the controls in memory when the control is disposed of?  This issue is causing us a lot of pain. 

hi,

it seems infragistics are unwilling to resolve this issue.

i've contacted them back in june of last year, several versions since the issue has not yet been resolved.

i created a fix for this issue that works on v.73 i dont know if it will work on later versions, but i suspect it might.

what we did was to directly access and release the objects that hold references to all our UI objects.

this code will be available soon on my blog.

if you want to get it sooner, contact me and i will send you a copy of the source code.

i have to say, i am very dissapointed with infragistics for not fixing this core issue.

this is not a "minor issue". this is a fundamental design flaw.

sending a product that cannot be garbage collected and results in huge memory leaks, and not resolving it version after version showes complete disragard for me as a client.

I agree.  This is very disappointing and a serious design flaw.  I won't be able to recommend their product suite to clients until this is resolved. 

I'd like to see how you resolved this issue and will look for your blog.  Thanks.

Just saw your answer. Sorry about that.

I'll try it out my self :)

Having the same issues!

I must admit, like Pat H, that I can not recommend Infragistics to any companies as long as they have this issue.

Pat, did it work on 2008.3 as well, or??

Actually, this won't be necessary.  I found the problem and the problem was ours not Infragistics.  Since Matt double checked your source code and said the Dispose should be cleaning as expected, I went back into our code and looked much deeper than I initially did and found a case were one of our controls was creating an Infragistics control but not adding it to its' own Controls collection so when it was disposed of the child control (the Infragistics control) was not and that is what the memory profile screen shot was showing.  When I saw that, I googled for this issue and found these forum entries and assumed my issue was related.  While preventing a control's finalizer from being called and thus preventing the Dispose from being called is a problem, it is not what was leading to our issue.  We are using CAB and so when a WorkItem is terminated, its' SmartParts are disposed of so I am not as concerned about having to manually call the Dispose on a control to get this clean up to happen since CAB will do this for us.  Long story short, I am once again a happy customer.  Although once I cleaned up this issue, I found what looks like a similar issue where we are leaving a UltraWinChart.IGWinTooltip.LocationChangedHookedControls hooked up.  I assume we are not disposing of a Infragistics chart control here.  

Thanks yossin.  I will take a look and let you know how it goes.