C# と VB.NET の質問掲示板

No79914 の続きと言うことで

クライアント側の実装がしたいのだよね？
# サーバ側の処理はここでは考えない

微妙に状況がわからないのだけど WebClient を使わない理由はなぜだろう。
クライアント→サーバにリクエストを送り、サーバ→クライアントへの返信を受け取る処理を
メッセージループなしで行うには System.Net.WebClient が最短手順だと思うのだけど。

MSDN サンプルのほぼそのままだけど、コンソールアプリケーションにて
System.Net.WebClient w = new System.Net.WebClient();
byte[] webcontents = w.DownloadData("http://localhost/");
Console.WriteLine(Encoding.ASCII.GetString(webcontents));
だけで当方期待通りの動きを確認済み。

native なら curl あたりを提案するとこだけど、たぶん curl にできることなら WebClient でもできる。

No79931 の「プロセス間通信」というのは、オイラが誤読していないのであれば

              http                                                      IPC
（サーバー） ------ （画面表示無しの通信専用プロセス、リサイクルあり） ----- （主プログラム）

の構成してみたらどう？という意味だと思う。

主プログラムは子プロセスとして通信専用プロセスを起動する
通信専用子プロセスはサーバーと http 通信し、主プログラムに結果を返す。
（１回ごとでもいいし一定時間ごとでもいいけど）通信専用子プロセスは終了する（終了させる）と
通信専用子プロセス自体にリソースリークがあっても OS が回収してくれるんぢゃないの？
→通信専用子プロセスは WebBrowser なり WebKit を使っても問題ない

これは目的と手段がいれかわっている手だよね。
通信したい→ WebKit なら通信できる→ WebKit を使う事が目的にすり替わっている気のせいがする。
課題が「 WebBrowser/WebKit を使うこと」ならばこれでよいと思うが
課題が「所定の http 通信したい」なら、これは解決策としては遠回り杉っつか下策と思う。

主プログラムと通信専用子プロセスの間の IPC はなんでもいい。
ファイルでもいいしパイプでもいいし共有メモリでもいいだろう。
オイラなら慣れてる native で cURL.exe を起動しパイプで結果受け取るかな

--------

http も IPC の１つなわけだけど、その http を喋るサーバソフトはもうあるわけだよね。
そのサーバソフトを作り直して http でない別の IPC プロトコルを喋らせようということが聞きたいの？

> ところが、WebClient を連続で使っていると応答が戻ってこ無いことがあったのです。
その理由を追求してサーバ側なりクライアント側なりを修正するのがいちばん「まとも」な手だと思う。

通信したい→ WebClient では失敗する→失敗する原因を追究する
cookie が足らないとか、連続アクセス制限にひっかかっているとか、 UA 文字列が間違ってるとか。
オイラ的には WebClient 自体に問題があるとは思えない。

> RaiseEventでメソッドを実行してやれば良いのはわかるのですが、返すとしたらどう返すかわからなくなってしまいました。
> １つ目のサンプルでは一応返していますが、クラスライブラリで
> Return "Get Msg :" & AMsg
> しているだけで、サーバープログラムの方では何もしていませんよね。。。

???
たとえば、サーバ側の処理が「Integerを受け取ってその2倍の値を返す」なら、
サーバ側の記述は
Public Function Mul2(ByVal src As Integer) As Integer
  Return src * 2
End Function
になるだけですよね？
クライアント側は
Dim ret As Integer = remoteObject.Mul2(10)
と普通にメソッドを呼び出すだけ。