定期的に実行されるユーザー インターフェイスを備えた無人アプリがあります。
VB.NETアプリです。サービスまたはフォームのない Windows アプリケーションとして開発される代わりに、フォームを使用して開発され、すべてのコードが form_load ロジックに配置され、プログラムを終了するコードの最後の行として「END」ステートメントが配置されました。
不要な Windows フォーム リソースを使用するプログラムを作成する以外に、起動ロジックを BAS ファイルの MAIN サブに配置するように変更するために、このコードを送り返してやり直しを求める説得力のある理由はありますか?
プログラムが (継続的に実行されるのではなく) ミックスに出入りする場合、それをサービスにする意味はありますか?
アプリが Form で開発されている場合、アプリに MessageBox コマンドがなくても誰も応答しないダイアログ ボックスが表示されることを心配する必要がありますか?
おそらくダイアログを避けるために、アプリが無人で実行されていることを確認できるものがVB6にあったことを思い出します。
これが実行されない条件があるかどうかはわかりません。
ただし、コードが今後一緒に作業する誰かによって配信された場合は、ベスト プラクティス (これはそうではありません) を理解し、ベスト プラクティス コードに期待していることを理解するのに役立つ機会としてこれを検討します。配達する。
まず、フォームで実行する必要はありません。フォームはプレゼンテーション用にあるため、そこで行うべきではありません。
アプリケーションをサービスに変換することを混乱させたくない場合 (難しくはありませんが、非常に簡単でもありません)、コンソール アプリケーションを作成し、Windows タスク スケジューラでスケジュールする必要があります。
このようにして、必要なことを正確に実行する Main 関数を備えたコンソール アプリケーションを作成します。
いずれにせよ、プログラマーはウィンドウを表示できるので、メッセージボックスはありません。通信は、ローカル ファイル、Windows イベント、データベースへのログを介して行う必要があります。
それらのいずれかについてさらに情報が必要な場合は、私に尋ねてください。
それをサービスにしたくないのであれば、それがWindowsサービスでなければならないということは何も言われていません。タスクスケジューラなどを介して実行するようにスケジュールすることは、有効なオプションです。
ただし、開発者はこのアプリを作成するために「Windowsフォーム」プロジェクトではなく「コンソールアプリ」プロジェクトを選択する必要があるように思われます。
返却してください。アプリケーションは必要以上にかさばり遅くなりますが、それほど問題にはなりません。リソースが不足する可能性がやや高くなります。しかし、主な理由は、コンソール アプリへの変換が非常に簡単であることです。
コンソール ウィンドウをポップアップさせたくない場合は、次の手順を実行してください。
新しいクラス "Program.vb" を作成し、パブリック共有 Main() メソッドを追加して、"OnLoad" ロジックをフォームからこのメソッドに移動します。
次に、フォームを削除し、プロジェクトの起動オブジェクト (プロジェクト プロパティ ウィンドウで使用可能) を変更して、フォームの代わりに Program.Main を使用します。
これは、Windows フォーム リソースが使用されていなくても、同じ効果があります。その後、System.Windows.Form および System.Drawing への参照を削除できます。