Q&A
細かな解説までありがとうございました。
現在のトラブルについての状況が細かく判明しました。ありがとうございます。
やはり標準入出力の受け渡しには一工夫が必要なのですね。
ご教示いただいた通りCGIで設置する方法も含め、別の方法を模索したいと思います。
CGI以外の実現方法をご存知の方がいらっしゃるかもしれませんので、しばらく質問はオープンにさせていただき、時機を見てクローズさせていただきます。ご回答、ありがとうございました。
ASP.NETで別プロセスとしてexeを動作させ、そのexeの標準出力を得たいと考えています。
具体的に想定している使用ケースは以下の通りです。
- webページに利用者がアクセスし、文字列を入力する
- 入力された文字列をwindowsサーバ側にインストールしてあるexeファイル(コンソールアプリケーション)に引数として渡し、実行する
- 得られた出力をwebページ上に表示する
ここでVisualstudio上でのデバッグはうまく動作し、タスクマネージャでもコンソールウィンドウホストが起動することが確認できているのですが、いざ発行してasaxファイルを配置→実行しても、なにも値が返ってきません。コンソールウィンドウホストが立ち上がる気配もありません。
ASP.NETではexeを呼び出すような処理を記述する場合、何か気を付けたり特殊な処理をしなければいけないのでしょうか。
どうぞご教示ください。よろしくお願いします。
開発はwindows serverにインストールしたvisualstudioでおこなっています。
参考までに問題個所のソースを記述します。
lang
1string FileName = @"C:\Program Files (x86)\動作させたい.exe"; 2 3ProcessStartInfo psInfo = new ProcessStartInfo(); 4Process mp = new Process(); 5 6mp.StartInfo.FileName = FileName; 7mp.StartInfo.Arguments = "引数"; 8mp.StartInfo.UseShellExecute = false; 9mp.StartInfo.RedirectStandardInput = true; 10mp.StartInfo.RedirectStandardOutput = true; 11mp.StartInfo.CreateNoWindow = false; 12mp.Start(); 13 14mp.StandardInput.WriteLine("ユーザーが入力した文字"); 15mp.StandardInput.Close(); 16 17String s = mp.StandardOutput.ReadToEnd(); 18//→sをブラウザに表示させる
回答3件
0
開発環境では IIS Express 上で動かしいて ASP.NET から起動するコンソールアプリは期待通り動いたが、運用環境で IIS にデプロイすると動かないと言っているのですよね？
であれば、IIS Express で動かしたときと IIS で動かしたときのワーカープロセスの違いを認識して下さい。（そのあたりが認識されてないと、今後また同様な問題で悩むことになるかもしれません）
IIS Express では質問者さんが Visual Studio を立ち上げた時のアカウント（管理者アカウント？）で Web アプリは動いているはずです。一方、IIS 上で動かした場合はアプリケーションプールのアカウントになります。
そうすると、IIS Express ではユーザー対話モードでアプリが実行され、IIS ではそうではないということになります。（前者は Environment.UserInteractive プロパティが true、後者は false になるので調べてみてください。true / false でどう違うかは MSDN ライブラリを読んでください）
さらに、Windows Server 2008 から採用されている Session 0 分離というセキュリティ対策による制約もあります。詳しくは、以下の記事からダウンロードできる word 文書を見てください。
Impact of Session 0 Isolation on Services and Drivers in Windows
https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653293(v=vs.85)
解決策は UI を使わないことです。
あと、開発環境でも IIS Express は使わないで、ローカル IIS を使うことをお勧めします。そうすれば今回のようなトラブルは未然に防ぐことができます。今回の問題は UI が使えないことによるものですが、それだけでなく、アクセス権の違いという問題でまた悩むことになるかも。
投稿2018/03/16 10:08
編集2018/03/16 10:10
退会済みユーザー
総合スコア0
0
ベストアンサー
ASP.NETで稼動するプロセスは、通常、ASP.NET用のWindowsサービスのコンテキストで動作して、適切な権限を割り当てています。Windowsサービスはデスクトップとの対話ができないようになっているので、従って標準入出力のハンドルもあらかじめ閉じられていて、プロセスを起動できても、標準入出力を介したやり取りは恐らくできないと思います。
Visual Studio でのデバッグですと、そのデバッグしているユーザーアカウントでローカルなデバッグ用ASP.NETサーバーとデバッグ対象のプログラムが動作するので、ASP.NETの本番用とは動作環境が異なることになります。
もし、HTMLのフォームに入力された値を標準入出力でやり取りしたいのであれば、ASP.NETではなく、CGIとして設置する必要があります。
2018/03/22 12:48 追記
※コメントに書こうとしましたが、長文になりましたので追記します。
そもそもこの構成が実現可能なのかどうかも含めて、何卒、ご教示くださいませ。
その構成ですと不可能だと思います。バッチファイル中で標準入出力を利用して作成したファイルは意図通りの結果とならないと思ってください。パイプ(|)もリダイレクト(>)も、標準入出力が使えてこそ、意図通りに動作します。
詳細な理由は別回答でSurferOnWwwさんが述べられている内容を理解する必要があります。
端的に書くと「IISは、ユーザー対話モードでアプリを実行しない、ワーカープロセスから起動したバッチファイル内では標準入出力を使えない」と言うことになるのですが、これは回避できません。
IISではないですが、私も過去、Windowsサービス中で標準入出力で他プロセスとやり取りしようとして挫折しました。と言いますかアプローチが間違っているのでとっとと違う方法にしたのですが。
話を戻しますと、、
実行したいexeがC\Program Filesにあるのが原因だと思うのですが、
C:\Program Files下にあっても、起動自体はできてます。`"echo "入力データ" | 実行ファイル" として、実行したいEXEに標準入力を流し入れようとすること自体が不可能、と言うことです。
CGIであれば、そのCGIプロセスが標準入力として取り込めるようにIISが準備してから呼び出します。
（UNIX系OSのように、ソケットのハンドルを標準入出力のハンドルに繋ぎ換えているはず）
テキストファイルは生成されるものの、空のテキストファイルが生成されてしまいます…(ローカル実行なら問題なく動作します)
(>)の指定でバッチファイルを実行しているCMD.EXEがファイルを新規で開くものの、標準入力が流れてこないまま終わり、ファイルを閉じる為、空になってます。
ローカルで実行するとOKなのは、デスクトップで実行しているからです。（デスクトップで実行している、などと言う表現がそもそも分かりづらいのですが、要はユーザーがログオンして画面上で操作している、と思ってください）
私の先の回答では、ワーカープロセス内から
実行したいexe /IN 入力データが入ったファイル /OUT 出力結果を格納するファイル
のような感じでコマンドラインオプションを指定できるよう、実行したいexeプログラムを改変する、と言う提案のつもりでした。実行したいexeのプログラム自体をRockyさんの方で改変できないのであれば、CGIとして動作させるしか簡単な方法はないように思います。
あと方法として思いつくものとしては（まったくお勧めできませんが）、IISのワーカープロセスと名前付きパイプ等のプロセス間通信を行うデスクトップアプリをひとつ作成してログオンしたデスクトップに常駐させ、ワーカープロセスからのリクエストに応じて実行し、結果をワーカープロセスへ返す、とのような方法です。これだとデスクトップからログオフするともう使えないので致命的です。
投稿2018/03/16 09:30
編集2018/03/22 03:49
総合スコア9183
プロセスは実行できるので、標準入出力を使わなければいいわけです。
ASP.NETで取得したWEBページの文字列をそのプロセスのコマンドラインオプション、またはファイルに指定して渡し、プロセスを起動したらその出力はファイルへ保存して、そのファイルをASP.NET側で読み出してレスポンスに返せば良いのではないでしょうか。（その実行時のユーザー権限は気にしないとハマりますが）
な、なるほど、、、！！ファイル出力してしまえばいいんですね。
大量のアクセスが見込まれるので、ファイルロックなど運用的に厳しい？かも？
いや、それも設計次第ですね。検証してみます！本当にありがとうございました！
大量のアクセスやいち実行単位の時間が長くなるのが予想されるのであれば、たとえばそのプロセスもWindowsサービスにして、うまくスレッド単位で細切れに処理をすることでパフォーマンスの向上が図れると思います。名前付きパイプ等のプロセス間通信が必要にもなってきますが。いずれにせよ設計次第ですね。
>dodox86さん
先日は丁寧なご回答ありがとうございました。ご指摘、想定の内容に見事にハマりましてさらにご指導賜りたく存じます。
IIS_USERのアクセス権限のあるフォルダに、[echo "入力" | "実行したいexe" > 出力.txt]となるバッチを配置し、webリクエストから実行してみたところ、テキストファイルは生成されるものの、空のテキストファイルが生成されてしまいます…(ローカル実行なら問題なく動作します)
実行したいexeがC\Program Filesにあるのが原因だと思うのですが、どのように回避すればよいかわからずつまずいてしまいました。(インストールするタイプのソフトで、exeの場所を動かせません)
そもそもこの構成が実現可能なのかどうかも含めて、何卒、ご教示くださいませ。
回答に追記しました。
回答の編集、ありがとうございます。やはり基本的な方向が間違っているのですね。
内容再度理解に努め、CGIの実装に向けて勉強を始めたいと思います。
至らないところが散見されるにもかかわらず、丁寧なご回答誠にありがとうございました。
あ、CGIとして実装する場合の補足ですが、そうだとすると「実行したいexe」の標準出力がそのままHTTPレスポンスのcontent(html)の出力になってしまうのでご注意ください。それはそれでクリアするのが難しい課題が出てくるかもしれません。（勉強される内にすぐ分かると思いますが）
ええー！そうなんですか… exeの出力を加工してからレスポンス返したいのですが、無理なんですねorz
では、exeファイルを標準出力ではなくファイル出力するようにラップする方法を検討しようかと思います。（サードパーティ製のソフト同梱使用が必須案件で、この呪縛が非常に効いています…）
せっかくの機会なのでCGI実装についてもちゃんと勉強してみますね。わざわざありがとうございます。
無理とも言い切れません。exeの修正内容次第です。
> exeファイルを標準出力ではなくファイル出力
これができるならCGIでなく、話しが戻りますが当初のワーカープロセス案で行けるはずです。CGIも含め調査ご検討ください。
右往左往している最中ですが、強力な道しるべをありがとうございました。試行錯誤して頑張ります。
0
まずはそこにログ仕込むとかデバッグ用出力させるとかで、本当にそこに到達してるかを見てみればどうでしょう
投稿2018/03/16 08:48
総合スコア87774
プロセスを生成する前後でログを出したりなどして動作を確認していますが、
本番環境では空の出力を受け取って、空の文字列を出力するだけです。
（＝exeプロセスの生成がされないまま、コードが先に進んでしまいます）
ASP.NETではそもそもexeの実行が無理なのでしょうか？
すみません、おっしゃられたようにプロセスのIDをログで出すようにしたところ、ちゃんとIDが生成されていました。どうやら標準出力の受け渡し？で失敗しているようです。しばらく調査します。
ああ、標準入出力があさって向いてるってのはありがちっちゃーありがちですね。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/03/22 02:24