我有一个问题，它看起来像一个内存泄漏我的应用程序（应用程序随着时间的推移使用更多的内存，一个大约一周的工作后挂起）。

I'm having an issue which looks like a memory leak in one of my applications (the application uses more memory over time, an after about a week of work it hangs).

我已经检测并修复相关的课程我已经写了一些泄漏（比较有sos.dll采取堆转储透露他们迅速），和那些在数不再增加。

I've detected and fixed some leaks related to classes I've written (comparing heap dumps taken with sos.dll revealed them quickly), and those no longer increase in number.

目前，能够显着提高随着时间的唯一的事情是的WeakReference 实例，这在一个稳定的速率增加1000个新的的WeakReference 每分钟的实例。

Currently, the only thing that dramatically increases over time are WeakReference instances, which increase at a steady rate of 1,000 new WeakReference instances per minute.

我的code不使用的WeakReference 直接，我从来没有创建这些我自己。

My code doesn't use WeakReference directly, I never create those myself.

这是什么原因这么多的的WeakReference 实例被创建？

What could cause so many WeakReference instances to be created?

我用VB.NET，Visual Studio 2008和.NET 3.5

I'm using VB.NET, Visual Studio 2008 and .NET 3.5

推荐答案

是的，这是在VB.NET组件相当臭名昭著的泄漏。它是由跟踪与该WithEvents关键字声明的事件弱引用造成的。这种跟踪是为了支持编辑并继续。它泄漏在一个类中声明的每一个WithEvents就事件的WeakReference的一个实例。调试器需要被附接到释放那些WeakReference的对象。

Yes, this is a fairly infamous leak in VB.NET assemblies. It is caused by weak references that keep track of events that are declared with the WithEvents keyword. This tracking is done to support Edit and Continue. It leaks one instance of WeakReference for every one WithEvents event declared in a class. The debugger needs to be attached to release those WeakReference objects.

解决方法很简单。发货发布版本，而不是调试版本。

The workaround is simple. Ship the Release build, not the Debug build.