基本的にシングルスレッドでデータベースから次々にメールを送信するメッセージキューをここに作成しました。最初に、これは継続的なプロセスであるため、Windowsサービス上にある必要があり、理想的なソリューションのように聞こえたと思いましたが、マネージャーと話したのではなく、同じリポジトリにある方がよいと彼は言いました。プロジェクト全体と、while（true）ステートメントを入力した場合。そうすれば、本番環境にデプロイするときに、Windowsサービスなどのインストールについて心配する必要はありません。しかし、ここで私が思うのは、そのようにすると、Webサーバーに多くの望ましくないプレッシャーがかかるということです。
どちらに行けばいいのかわかりません。助言がありますか？
別のWindowsサービスを使用します。
このサービスはアプリケーションのパーティであるため、その存続期間はアプリケーションプールプロセスの存続期間に依存します（もちろん、使用しているIISのバージョンによって異なります）。このように、アプリケーションプールを変更することを選択するたびに設定では、メッセージジョブもそれに依存していることを覚えておく必要があります。アプリプールのリサイクル設定を設定すると、ジョブが突然機能しなくなった理由などを理解するのに苦労する可能性があります。
私は間違いなく、バックグラウンドで電子メールキューを処理するためのWindowsサービスをお勧めします。上司に提案できるポイントは次のとおりです。
installutilインストール/アンインストールのためにバッチファイルを使用してプロジェクトに追加します。アップグレードとは、サービスを停止し、サービスを更新して.exe、サービスを再開することです。また、単純にコマンド ライン アプリケーションを作成し、それを Service+ のようなものでラップして、サービスのように動作させるというルートに進むこともできます。また、必要に応じて（いつでも実行したいときに）コマンドラインアプリケーションのように実行したり、必要に応じて他のアプリケーションから起動/実行したりできるなど、他の機能も利用できます。さまざまな動作も構築できます...連続モード、おそらく一度に1つ（または100など）を処理して終了し（Service +に再起動させます）、または必要に応じてその他何でも。