无人值守应用最佳实践问题
我们有一个无人值守的应用程序，带有定期运行的用户界面。
它是一个 VB.NET 应用程序。它不是作为服务或无表单的Windows应用程序开发的，而是使用表单开发的，所有代码都放在form_load逻辑中，并用“END”语句作为最后一行代码来终止程序。
除了生成使用不需要的 Windows 窗体资源的程序之外，是否有一个令人信服的理由将此代码发回以进行修改以将启动逻辑放入 BAS 文件的 MAIN 子文件中？
如果程序要进入和退出混合（而不是连续运行），那么将其作为服务有什么意义？
如果应用程序是使用表单开发的，我是否需要担心会出现一个即使应用程序中没有 MessageBox 命令也没有人会响应的对话框？
我记得 VB6 中曾经有一些功能，您可以在其中检查应用程序是否在无人值守的情况下运行，大概是为了避免对话框。
We have an unattended app w/o a user interface that is is periodically run.
It is a VB.NET app. Instead of it being developed as a service, or a formless Windows application, it was developed with a form and all the code was placed in the form_load logic, with an "END" statement as the last line of code to terminate the program.
Other than producing a program that uses unneeded Windows form resources, is there a compelling reason to send this code back for rework to be changed to put the start up logic in a MAIN sub of a BAS file?
If the program is to enter and exit the mix (as opposed to running continuously) is there any point in making it a service?
If the app is developed with a Form do I have to worry about a dialog box being presented that no one will respond to even if there are no MessageBox commands in the app?
I recall there used to be something in VB6 where you could check an app as running unattended, presumably to avoid dialogs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不知道是否存在无法运行的情况。
但是，如果代码是由您未来合作的人交付的，我会将此视为帮助他们了解最佳实践（事实并非如此）的机会，并帮助他们了解您期望最佳实践代码被交付。
I don't know whether there are conditions where this will not run.
However, if the code was delivered by someone you will work with going forward, I would look at this as an opportunity to help them understand best practices (which this is not), and to help them understand that you expect best-practice code to be delivered.
首先，您不需要它在表单中运行。
表格是用于演示的，所以不应该在那里完成。
如果您不想将应用程序转换为服务（不难，但也不是很容易），您应该创建一个控制台应用程序，然后使用 Windows 任务计划程序对其进行调度。
这样，您就可以创建一个带有 Main 函数的控制台应用程序，它完全可以满足您的需要。
不管怎样，程序员可以显示窗口，所以不应该有任何消息框。任何通信都应通过记录到：本地文件、Windows 事件、数据库来完成。
如果您想了解有关其中任何一个的更多信息，请询问我。
First of all, you don't need it to be run in a Form.
Forms are there for Presentation, so it should not be done there.
If you don't want to mess with converting the application a Service (not difficult, but not very easy neither), you shoud create a Console Application, and then, schedule it with Windows Task Scheduler.
This way, you create a Console Application, with a Main function, that does exactly what you need.
Anyway, the programmer could show windows, so there should not be any messagebox. Any communication should be done via Logging to: local files, windows events, database.
If you want more information on any of them, ask me.
如果您不希望它成为一项服务，则没有任何规定它必须是 Windows 服务。通过任务计划程序或类似的东西安排它运行是一个有效的选项。
但是，听起来开发人员确实应该选择“控制台应用程序”项目，而不是“Windows 窗体”项目来创建此应用程序。
If you don't want it to be a service, nothing says that it has to be a windows service. Scheduling it to run via the Task Scheduler or something similar is a valid option.
However, it does sound like the developer should have choose a "Console App" project, instead of a "Windows Forms" project to create this app.
寄回来。该应用程序比它需要的更庞大、更慢，尽管这不是什么大问题。资源耗尽的可能性更大。但主要原因是：将其转换为控制台应用程序非常容易。
Send it back. The application is bulkier and slower than it needs to be, although that won't be much of an issue. It is somewhat more likely to run out of resources. But the main reason: converting it to a console app is very easy.
如果您不喜欢弹出控制台窗口，只需执行以下操作即可。
创建一个新类“Program.vb”，添加一个公共共享 Main() 方法，并将“OnLoad”逻辑从表单移至此方法。
接下来删除窗体，并更改项目启动对象（在项目属性窗口中可用）以使用 Program.Main 而不是窗体。
这将具有相同的效果，而不使用 Windows 窗体资源。然后，您可以删除对 System.Windows.Form 和 System.Drawing 的引用。
If you don't prefer for the Console window to popup, simply do the following.
Create a new class "Program.vb", add a public shared Main() method, and move the "OnLoad" logic from the form to this method.
Next delete the form, and change the project start up object (Available in the project properties window) to use the Program.Main instead of the Form.
This will have the same effect, without the windows forms resources being used. You can then remove the references to System.Windows.Form and System.Drawing.