我正在开发一个 VB.NET WinForms 应用程序，它是由 Visual Studio（最初是 1.0 或 1.1）从 VB6 代码（它本身是从 VB5 升级的）“升级”的。除了我在接管这个应用程序的维护后创建的几个新表单之外，应用程序中的所有表单都有一个名为 DefInstance 的方法，如果有的话，它允许您获取表单的内存副本。我不知道为什么：当它不在我工作的范围内时，我什么时候需要引用内存中的表单对象。在我看来，这违反了各种合理的编程原则，并且似乎是内存泄漏或更糟的邀请。
问题：（1）这个 DefInstance 东西仅仅是这个应用程序的 VB6 遗产的不幸残余，以及（2）我应该在整个应用程序中删除 DefInstance 方法吗？
我从 Microsoft 员工那里收到了这个答案：
http://msdn.microsoft.com/en-us/library/aa289529(VS.71,printer).aspx
In short, DefInstance is a "not best practices" compatibility method for older apps that haven't been made into true .NET WinForms apps. Being a web programmer until earlier this year I had never worked with VB6 "WinForms" applications nor had to deal with the compatibility compromises that the upgrade wizard makes in forcing them into .NET.
Yes, the default instance is a terrible byproduct of importing the application through the upgrade wizard. Using the default instance was a VB habit in pre dot net versions because forms were always resident in memmory as a default instance, although you could also g=create additional instances.
As Parvenu74 said, it is not a best practise. That being said, you should be very careful when removing it from an imported application because of side affects and references where it might be being used. Your best bet is to not use it in new code that you develop and slowly migrate yourself away from the "converted" code over time. As was mentioned above the default instance stuff was re-instroduced in VB 2005, but it's use is highly discouraged.
正如您所提到的，它可以让您获得对表单的引用。
我见过很多这样写的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。