我们有一个定期运行的无人值守应用程序 w/oa 用户界面。
它是一个 VB.NET 应用程序。它不是作为服务或无窗体的 Windows 应用程序开发的，而是使用窗体开发的，所有代码都放在 form_load 逻辑中，并以“END”语句作为终止程序的最后一行代码。
除了生成使用不需要的 Windows 窗体资源的程序之外，是否有令人信服的理由将此代码发回以进行更改以将启动逻辑放入 BAS 文件的 MAIN 子文件中？
如果程序要进入和退出混合（而不是连续运行），让它成为服务有什么意义吗？
如果应用程序是使用表单开发的，我是否需要担心即使应用程序中没有 MessageBox 命令也会出现一个没有人响应的对话框？
我记得在 VB6 中曾经有一些东西可以检查应用程序是否在无人看管的情况下运行，大概是为了避免对话框。
我不知道是否有条件不会运行。
但是，如果代码是由您将与之合作的人交付的，我会将此视为帮助他们理解最佳实践（事实并非如此）的机会，并帮助他们了解您期望最佳实践代码交付。
首先，您不需要它在表单中运行。表格是用于演示的，所以不应该在那里完成。
如果您不想将应用程序转换为服务（不难，但也不是很容易），您应该创建一个控制台应用程序，然后使用 Windows 任务计划程序安排它。
这样，您就可以创建一个带有 Main 功能的控制台应用程序，它完全可以满足您的需求。
无论如何，程序员可以显示窗口，所以不应该有任何消息框。任何通信都应通过记录到：本地文件、Windows 事件、数据库来完成。
如果您想了解有关其中任何一个的更多信息，请问我。
如果您不希望它成为服务，那么没有什么说它必须是 Windows 服务。安排它通过任务计划程序或类似的东西运行是一个有效的选项。
但是，听起来开发人员应该选择“控制台应用程序”项目，而不是“Windows 窗体”项目来创建此应用程序。
把它退回。该应用程序比它需要的更庞大和更慢，尽管这不是什么大问题。它更有可能耗尽资源。但主要原因是：将其转换为控制台应用程序非常容易。
如果您不希望弹出控制台窗口，只需执行以下操作。
创建一个新类“Program.vb”，添加一个公共共享 Main() 方法，并将“OnLoad”逻辑从表单移至此方法。
接下来删除表单，并将项目启动对象（在项目属性窗口中可用）更改为使用 Program.Main 而不是 Form。
这将具有相同的效果，而无需使用 Windows 窗体资源。然后，您可以删除对 System.Windows.Form 和 System.Drawing 的引用。