web-dev-qa-db-ja.com

「サービスがデスクトップと対話できるようにする」の代わりに？

サーバーにWindowsサービス（C＃）をインストールして、実行可能ファイル（C＃）を10分ごとに起動して、あるディレクトリから別のディレクトリにいくつかの画像を処理しています。ユーザーとの対話は必要ありません。それでも、実行可能ファイルは出力ウィンドウであるため、サービスを実行するには、「サービスがデスクトップと対話できるようにする」チェックボックスを有効にする必要がありますこれは 安全ではなく悪い習慣と見なされます。この問題についてどうすればよいですか？実行可能ファイルをWindowsサービスから分離するのが好きです。

  • デバッグが容易になり、完全なWindowsサービスの再デプロイは必要ありません。
  • 同じWindowsサービスを使用して、異なる間隔で複数の実行可能ファイルを起動することがあります（ただし、すべて同じプロジェクトに関連しています）。

編集：

デスクトップとの対話が有効になっていない場合、コンソールアプリケーションは正しく実行されず、Windowsログ内に次のエラーが表示されます。

Faulting application myapp.exe, version 1.0.0.0, time stamp 0x4b8304c3, 
faulting module KERNEL32.dll, version 6.0.6002.18005, time stamp 0x49e03821, 
exception code 0xc0000142, fault offset 0x00009eed, process id 0x10ec, 
application start time 0x01cab736950a64b5.

デスクトップインタラクションが有効になると、アプリケーションは正常に実行されます。

何かご意見は？

お時間をいただき、誠にありがとうございます。

c#windows-servicesexe
19
jdecuyper

Vista以降を使用していて、ユーザーとの対話は実際には必要ないが、実行するための対話型exeがある場合、 セッション0分離機能 は 'に関する懸念のいくつかを軽減するのに役立つはずです。サービスをデスクトップと対話させることに関する「悪い習慣」（セッション0では物理コンソールがありません）。

このセッション0の分離により、特権のないユーザーがさまざまなセッションでインタラクティブデスクトップを取得するときに、サービスで シャッター攻撃 を実行できなくなります。シャッター攻撃は、この「デスクトップとの相互作用」が悪い習慣と見なされた主な理由であり、Vista以降を使用している場合、それを回避できない（またはそれを行うために多くの労力を費やす必要がある）場合は問題ありません。

ですから、問題なく動作していれば、おそらく大丈夫です。

もちろん、OSの更新後は動作が停止する可能性があるため、対話性への依存を実際には必要ないので、移動する準備をしておくことをお勧めします。

11
Aryabhatta

私はこれが少し遅いことを知っていますが、この状況では私はタスクスケジューラを使用し、Windowsサービスを気にしません。タスクスケジューラには包括的なスケジューリングオプションのセットがあり、問題なくコンソールアプリケーションを実行できます。

5
Robert

可能であれば、移動を処理する実行可能ファイルを、出力ウィンドウを使用しないように書き直すことをお勧めします。出力のない標準のコンソールアプリケーションの場合、「サービスにデスクトップとの対話を許可する」ことなく、サービス内から実行できます。これにより、サービスを変更することなく、すべてのメリットが得られます。

2
Reed Copsey

サブプロセスは単なるコンソールアプリケーションですか？私はWindowsサービスを作成していませんが、ウィンドウなしでサブプロセスを開始するだけで十分だと思います。 ProcessStartInfoを取得するProcess.Startのオーバーロードを使用し、ProcessStartInfo.CreateNoWindowをtrueに設定します。

http://msdn.Microsoft.com/en-us/library/system.diagnostics.processstartinfo.createnowindow.aspx

2
Weeble