我正在开发一个 VB.NET WinForms 应用程序，该应用程序由 Visual Studio（最初是 1.0 或 1.1）从 VB6 代码（它本身是从 VB5 升级）“升级”的。除了我在接管这个应用程序的维护后创建的几个新表单之外，应用程序中的所有表单都有一个名为 DefInstance 的方法，如果有的话，它允许您获取表单的内存副本。我不知道为什么：当它不在我工作的范围内时，我什么时候需要引用内存中的表单对象。在我看来，这违反了各种合理的编程原则，并且似乎是内存泄漏或更糟的邀请。
问题：(1) 这个 DefInstance 东西仅仅是这个应用程序的 VB6 遗产的不幸残余，以及 (2) 我应该在整个应用程序中删除 DefInstance 方法吗？
【问题讨论】：
标签： vb.net winforms vb6 vb6-migration
我从一名 Microsoft 员工那里收到了这个答复：
http://msdn.microsoft.com/en-us/library/aa289529(VS.71,printer).aspx
简而言之，对于尚未制成真正 .NET WinForms 应用程序的旧应用程序，DefInstance 是一种“非最佳实践”的兼容性方法。作为一名网络程序员，直到今年早些时候，我从未使用过 VB6“WinForms”应用程序，也不必处理升级向导在强制它们进入 .NET 时造成的兼容性妥协。
【讨论】：
是的，默认实例是通过升级向导导入应用程序的可怕副产品。使用默认实例是预 dot net 版本中的 VB 习惯，因为表单始终作为默认实例驻留在内存中，尽管您也可以 g=创建其他实例。
正如 Parvenu74 所说，这不是最佳实践。话虽如此，在从导入的应用程序中删除它时应该非常小心，因为它的副作用和可能被使用的引用。您最好的选择是不要在您开发的新代码中使用它，并随着时间的推移慢慢地将自己从“转换”的代码中迁移出来。正如上面提到的，默认实例的东西在 VB 2005 中被重新引入，但它的使用是非常不鼓励的。
【讨论】：
正如您所提到的，它可以让您获得对表单的引用。
我见过很多这样写的VB：
Private Sub Command_Click()
Call DoStuff
End Sub
Private Sub DoStuff()
Form1.myTextbox.Text = "Bad Idea"
End Sub
DefInstance 允许 DoStuff() 在不传递控件的情况下继续工作。
请参阅此处：http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/6d7985b5-6db6-47a8-9e11-cbf114a48d37/ 了解更多信息。
【讨论】：
遗憾的是，VB8 (VS2005) 中添加了句法糖的有毒成分。现在，当 VB.NET 程序员无法理解每个线程都有一个单独的“Form1”实例时，他们会感到非常困惑。好消息：现在您绝对不再需要 DefInstance。
【讨论】：