title: Garbage collection when using anonymous delegates for event handling
body: <p><strong>UPDATE</strong> </p>
  
  <p>I have combined various answers from here into a 'definitive' answer on a <a href="https://stackoverflow.com/questions/1747235/weak-event-handler-model-for-use-with-lambdas/1747236#1747236">new question</a>.</p>
  
  <p><strong>Original question</strong></p>
  
  <p>In my code I have an event publisher, which exists for the whole lifetime of the application (here reduced to bare essentials):</p>
  
  <pre><code>public class Publisher
  {
      //ValueEventArgs&lt;T&gt; inherits from EventArgs
      public event EventHandler&lt;ValueEventArgs&lt;bool&gt;&gt; EnabledChanged; 
  }
  </code></pre>
  
  <p>Because this publisher can be used all over the place, I was quite pleased with myself for creating this little helper class to avoid re-writing the handling code in all subscribers:</p>
  
  <pre><code>public static class Linker
  {
      public static void Link(Publisher publisher, Control subscriber)
      {
           publisher.EnabledChanged += (s, e) =&gt; subscriber.Enabled = e.Value;
      }
  
      //(Non-lambda version, if you're not comfortable with lambdas)
      public static void Link(Publisher publisher, Control subscriber)
      {
           publisher.EnabledChanged +=
               delegate(object sender, ValueEventArgs&lt;bool&gt; e)
               {
                    subscriber.Enabled = e.Value;
               };
      }
  }
  </code></pre>
  
  <p>It worked fine, until we started using it on smaller machines, when I started getting the occasional:</p>
  
  <pre><code>System.ComponentModel.Win32Exception
  Not enough storage is available to process this command
  </code></pre>
  
  <p>As it turns out, there is one place in the code where subscribers controls are being dynamically created, added and removed from a form. Given my advanced understanding of garbage collection etc (i.e. none, until yesterday), I never thought to clear up behind me, as in the vast majority of cases, the subscribers also live for the lifetime of the application.</p>
  
  <p>I've fiddled around a while with <a href="http://diditwith.net/CommentView,guid,aacdb8ae-7baa-4423-a953-c18c1c7940ab.aspx#commentstart" rel="nofollow noreferrer">Dustin Campbell's WeakEventHandler</a>, but it <em>doesn't work with anonymous delegates</em> (not for me anyway).</p>
  
  <p>Is there anyway out of this problem? I really would like to avoid having to copy-paste boiler-plate code all over the shop.</p>
  
  <p>(Oh, and don't bother with asking me WHY we are creating and destroying controls all the time, it wasn't my design decision...)</p>
  
  <p>(PS: It's a winforms application, but we've upgraded to VS2008 and .Net 3.5, should I consider using the <a href="http://msdn.microsoft.com/en-us/library/aa970850.aspx" rel="nofollow noreferrer">Weak Event pattern</a>?)</p>
  
  <p>(PPS: Good <a href="http://#371150" rel="nofollow noreferrer">answer from Rory</a>, but if anyone can come up with an equivalent to the WeakEventHandler which avoids me having to remember to explicitly UnLink/Dispose, that would be cool...)</p>
  
  <p><strong>EDIT</strong> I must admit that I worked around this problem by "recycling" the controls in question. However the workaround has come back to haunt me as the 'key' I was using is apparently non-unique (sob). I've just discovered other links <a href="http://danylaporte.blogspot.com/2008/09/weakeventhandler.html" rel="nofollow noreferrer">here</a> (tried this - seems to be a bit <em>too</em> weak - GC clears delegates even if target is still alive, same problem with <a href="https://stackoverflow.com/questions/371109/garbage-collection-when-using-anonymous-delegates-for-event-handling/955928#955928">s,oɔɯǝɹ answer</a> below), <a href="http://code.logos.com/blog/2008/08/event_subscription_using_weak_references.html" rel="nofollow noreferrer">here</a> (forces you to modify publisher, and doesn't really work with anonymous delegates) and <a href="http://joshsmithonwpf.wordpress.com/2009/04/06/a-mediator-prototype-for-wpf-apps/" rel="nofollow noreferrer">here</a> (cited-as-incomplete by Dustin Campbell). </p>
  
  <p>It occurs to me that what I'm looking for may be semantically impossible - closures are designed to 'hang around even after I'm gone'. </p>
  
  <p>I've found another workaround, so I'll stick with that, pending a <a href="http://blogs.msdn.com/ericlippert/" rel="nofollow noreferrer">voice from the gods</a>.</p>