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

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[17]: ブラウザとローカルコンポーネントの連携

(過去ログ 15 を表示中)

[トピック内 20 記事 (1 - 20 表示)]　 << 0 >>

■5135 / inTopicNo.1)

　ブラウザとローカルコンポーネントの連携

▼■

□投稿者/ まどか (317回)-(2007/07/05(Thu) 13:58:42)

分類:[VB.NET (ASP.NET)]　

#なんと初のASPプロジェクトをやってます。。。

概要：
サーバにあるハードウェアに対して自動状態表示や要求通知をクライアントブラウザでおこなっているシステムです。

仕様：
あるハードウェアがサーバとつながっておりそれを制御するサーバサービスがあります。
クライアントにはサーバサービスとリアルタイム対話するコンポーネントがあります。
現行ではブラウザがラッパActiveXを呼び出し、
リンク先の実体DLLの内部でサーバサービスとバックグラウンドで対話しています。
でもってブラウザがイベント通知を受けて自動画面内容更新をしています。

質問：
上記仕様のクライアントコンポーネントを.NET化する計画なのですが
クライアントサイドのアセンブリを呼び出す方法がピンときません。
どのようなやり方が考えられるでしょうか？
GACに登録して呼び出すという形になるのでしょうか？
#コンポーネントの配布はできれば自動のほうが好ましいですが特に問いません。

引用返信 編集キー/

■5136 / inTopicNo.2)

　Re[1]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ Moo (62回)-(2007/07/05(Thu) 15:13:39)

2007/07/05(Thu) 15:22:52 編集(投稿者)

2007/07/05(Thu) 15:14:41 編集(投稿者)

<pre><pre>選択カテゴリの[ASP.NET]がひっかかるのですが
サーバで状態を把握してから
クライアントにその状態を伝えるために
クライアントが定期的にサーバに状態を問合せに行くような
作り（ポーリング）になっているのでしょうか。

リアルタイムに状況が把握したのであれば
.NET Remoting+Windowsサービスを利用して
TCPなどで通信してみてはどうでしょうか。
※この場合、Web技術は使いません...

サーバとクライアント間の通信の制約事項は
なにかありますか？
（例：ファイアウォールの設定で
開いているポートが80しかない）</pre></pre>

引用返信 編集キー/

■5138 / inTopicNo.3)

　Re[2]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (318回)-(2007/07/05(Thu) 15:42:38)

> 選択カテゴリの[ASP.NET]がひっかかるのですが

いえ、ひっかかって結構です。
ブラウザの画面を自動更新するのがメインの質問ですので。

> サーバで状態を把握してから
> クライアントにその状態を伝えるために
> クライアントが定期的にサーバに状態を問合せに行くような
> 作り（ポーリング）になっているのでしょうか。

TCPIPで独自プロトコル文字列を投げ合ってます。
そのクライアント側を.NET化して、ブラウザがそいつを扱う方法がわからないというか想像できません。

> リアルタイムに状況が把握したのであれば
> .NET Remoting+Windowsサービスを利用して
> TCPなどで通信してみてはどうでしょうか。
> ※この場合、Web技術は使いません...

情報の精度はおっしゃるとおりですが、その表現手段がブラウザなのです。

> サーバとクライアント間の通信の制約事項は
> なにかありますか？

今のところ私の質問は通信の仕組みとは別の話と認識しています。
という理由から
「クライアントサイドのアセンブリを呼び出す方法がピンときません。」
「GACに登録して呼び出すという形になるのでしょうか？」
と書きました。

引き続きよろしくお願いします。

引用返信 編集キー/

■5154 / inTopicNo.4)

　Re[3]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ Moo (64回)-(2007/07/05(Thu) 17:17:29)

なるほど。
>ブラウザの画面を自動更新するのがメインの質問ですので。
画面の自動更新はMETA REFRESHとか
Javascriptで行えばよいのではないでしょうか。

>「クライアントサイドのアセンブリを呼び出す方法がピンときません。」
クライアントのアセンブリを実行ということであれば
アセンブリを実行するActiveXを作成してみるのはどうでしょうか。
手順を書く時間が取れないので取り急ぎ
参考になるURLを貼っておきます。

http://www.vbdotnetheaven.com/UploadFile/dsandor/ActiveXControlInVBdotNET04112005081747AM/ActiveXControlInVBdotNET.aspx

Webサイトの信頼レベルをいじる必要があるため注意が必要です

引用返信 編集キー/

■5160 / inTopicNo.5)

　Re[4]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (319回)-(2007/07/05(Thu) 18:04:19)

> クライアントのアセンブリを実行ということであれば
> アセンブリを実行するActiveXを作成してみるのはどうでしょうか。

やはり直接アセンブリを扱うことはできないんですよね。。。
パス固定でReflectionってのもいまいち。。。

ありがとうございました。

#あ、何かご意見がある方は引き続きお願いします。m(_ _)m

引用返信 編集キー/

■5166 / inTopicNo.6)

　Re[5]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ 渋木宏明(ひどり) (265回)-(2007/07/05(Thu) 20:34:05)

> やはり直接アセンブリを扱うことはできないんですよね。。。

デフォルト構成では無理ですね。

> パス固定でReflectionってのもいまいち。。。

も、デフォルト構成ではセキュリティ例外が発生します。

今のところ、現状のカタチが一番安定していると思いますよ。

引用返信 編集キー/

■5247 / inTopicNo.7)

　Re[6]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (320回)-(2007/07/09(Mon) 09:16:41)

まどか＠金曜有休でした。

> 今のところ、現状のカタチが一番安定していると思いますよ。

ブラウザからクライアントにあるバイナリを呼び出す方法は実質ActiveXしかない
という解釈でよろしいでしょうか？

.NET化はいまどきのものにする、コンポーネントインターフェースを顧客に開放する
ということでMooさんご提示の方法(.NETでActiveXを作る)で考えています。

引用返信 編集キー/

■5248 / inTopicNo.8)

　Re[7]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ 渋木宏明(ひどり) (268回)-(2007/07/09(Mon) 09:44:29)

> ブラウザからクライアントにあるバイナリを呼び出す方法は実質ActiveXしかない
> という解釈でよろしいでしょうか？

「各クライアントの .NET の構成をいじらずに」という条件の下に、ということならそうなりますが、クライアントの .NET のセキュリティ設定を一部緩和すれば、ブラウザに直接貼り付けたマネージコントロールからもローカル資源にアクセスは可能です。

ActiveX コントロールについても、もやはりブラウザ設定で無効にすることが出来るので、結局はクライアント環境の設定に依存します。

> .NET化はいまどきのものにする、コンポーネントインターフェースを顧客に開放する
> ということでMooさんご提示の方法(.NETでActiveXを作る)で考えています。

cab 配布を狙っているなら、「もどき」は配布で苦労すると思いますよ。
「もどき」の動作概要と ActiveX コントロールの登録に必要なレジストリ設定についてひととおり知っているなら止めませんが。

インターフェースを公開するのが .NET 化の目的のひとつだとして、顧客はどのアセンブリをどうやって使うんでしょう？

.NET の原則に従うなら、ActiveX コントロールと顧客のアプリケーションが同じアセンブリを参照するためには

・GAC に登録されたアセンブリを参照する
・各アプリケーション（ActiveX コントロールを含む）が共通アセンブリのコピーを持つ

のどちらかになりますよね？

で、GAC に登録したらしたらで慎重に計画しないとトラブった時面倒だし、個別にアセンブリのコピーを持つなら ActiveX コントロール＝共有アセンブリである必要はないはずです。

ということなら、個人的には

・共通アセンブリを C# で作成する
・VC++ で ActiveX コントロールの「がわ」を作成して↑の共通アセンブリを使用する
・顧客アプリも↑の共通アセンブリのコピーを使用する

なんてあたりがお安い落としどころのような気がします。

引用返信 編集キー/

■5251 / inTopicNo.9)

　Re[8]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (321回)-(2007/07/09(Mon) 11:14:06)

> 「各クライアントの .NET の構成をいじらずに」という条件の下に、ということならそうなりますが、クライアントの .NET のセキュリティ設定を一部緩和すれば、ブラウザに直接貼り付けたマネージコントロールからもローカル資源にアクセスは可能です。
> ActiveX コントロールについても、もやはりブラウザ設定で無効にすることが出来るので、結局はクライアント環境の設定に依存します。

イントラなので十分にいじれます。
また、こてこての専用PCみたいなもんですから「設定変えないでね」は通用します。
なのでマネージドコントロールはActiveXから解放されるので魅力的です。
検討してみます。

>>.NET化はいまどきのものにする、コンポーネントインターフェースを顧客に開放する
> cab 配布を狙っているなら、「もどき」は配布で苦労すると思いますよ。

#「いまどき」「もどき」？
配布に関しても初期インストール作業OKなので心配はしていません。

> ・共通アセンブリを C# で作成する
> ・VC++ で ActiveX コントロールの「がわ」を作成して↑の共通アセンブリを使用する
> ・顧客アプリも↑の共通アセンブリのコピーを使用する

言ってたActiveXはブラウザのためだけでした。。。
顧客開放はおっしゃる共通アセンブリ(クライアントコンポーネント)になります。
なのでおっしゃる方法で今は考えています。

前述のとおり設定は柔軟にできるのですが
> ・VC++ で ActiveX コントロールの「がわ」を
マネージドコントロールのやり方より、ActiveXのほうがよいのでしょうか？
#ブラウザとの相性＞ASP.NETとの相性？

引用返信 編集キー/

■5287 / inTopicNo.10)

　Re[9]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ 渋木宏明(ひどり) (269回)-(2007/07/09(Mon) 17:34:10)

> イントラなので十分にいじれます。
> また、こてこての専用PCみたいなもんですから「設定変えないでね」は通用します。

ならマネージコントロールで行くのも十分「あり」ですね。

> 前述のとおり設定は柔軟にできるのですが
>>・VC++ で ActiveX コントロールの「がわ」を
> マネージドコントロールのやり方より、ActiveXのほうがよいのでしょうか？

んー、微妙ですね。
クライアント設定がコントロール可能ならどちらでもいいような気がします。

引用返信 編集キー/

■5288 / inTopicNo.11)

　Re[10]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (322回)-(2007/07/09(Mon) 18:03:20)

> ならマネージコントロールで行くのも十分「あり」ですね。

もう一度確認したらブラウザ用にも開放するという話でした。。。
顧客が使うツールがVS2005ならマネージドコントロールとActiveXどちらでも、
ホームページビルダーみたいなのだとActiveX
というようになるのでしょうかね。

とりあえず本体DLL＋Web用ラッパということはほぼ決まりです。

使用や用途を聞けば聞くほどWebである必要はないんですが
#本題のコンポーネント同士の通信がメインでWebサーバーへの要求がほとんどない。
既存業務Webシステムの上にのっけるということなんでねぇ。

初仕事なんでほんとご助言感謝します。＞ALL

引用返信 編集キー/

■5291 / inTopicNo.12)

　Re[11]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ 渋木宏明(ひどり) (270回)-(2007/07/09(Mon) 19:53:31)

> 顧客が使うツールがVS2005ならマネージドコントロールとActiveXどちらでも、
> ホームページビルダーみたいなのだとActiveX
> というようになるのでしょうかね。

意味不明気味ですが、要するにブラウザ上でスクリプティングできるかどうか、ってことなら可能だと思います。
（どこまで厳密な意味でマネージ昆とトールが "ActiveX コントロール" に見えるかってのは分かりませんが）

でも、そこまでお客が直接（邪魔くさいこと）言うなら、「がわ」は VC++ で普通に ActiveX コントロールにしておいた方が無難な気もしますね。

> 使用や用途を聞けば聞くほどWebである必要はないんですが
> #本題のコンポーネント同士の通信がメインでWebサーバーへの要求がほとんどない。
> 既存業務Webシステムの上にのっけるということなんでねぇ。

ロジックを Web サービスにしてサーバ側で処理を実行するようにして、それをブラウザから AJAX 的にスクリプトで非同期に呼び出すんでは駄目なのかな？

引用返信 編集キー/

■5303 / inTopicNo.13)

　Re[12]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (323回)-(2007/07/10(Tue) 11:36:39)

すごく基本的なことを確認してみますが、
マネージコントロール(Framework)であってもObjectタグ？の書き方？を知っていれば
どんなツールでも(それを呼び出す)Webページは作れる
ということですよね？

> 「がわ」は VC++ で普通に ActiveX コントロールにしておいた方が無難な気もしますね。

その方向が強いですが、マネージコントロールであれば開発ツールがVS2005で統一できるという利点もありますね。
前述の共通アセンブリを開放するわけですが、Webでも使えるようにと今回のActiveX云々も開放します。

> ロジックを Web サービスにしてサーバ側で処理を実行するようにして、それをブラウザから AJAX 的にスクリプトで非同期に呼び出すんでは駄目なのかな？

双方向イベント通知なので非同期は要求にはないですね。
今のところサーバー側サービスの提供するリモートオブジェクトへRemotingしようかと思ってます。
#現状はTCPですが。

引用返信 編集キー/

■5318 / inTopicNo.14)

　Re[13]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ 渋木宏明(ひどり) (271回)-(2007/07/10(Tue) 13:32:05)

> すごく基本的なことを確認してみますが、
> マネージコントロール(Framework)であってもObjectタグ？の書き方？を知っていれば
> どんなツールでも(それを呼び出す)Webページは作れる
> ということですよね？

object タグの書式は、ActiveX コントロールを扱う場合と少し異なります。

http://msdn2.microsoft.com/ja-jp/library/a7as3z1d(vs.80).aspx

なので、妙に親切なツール（＝例えば利用可能な ActiveX コントロールを一覧表示して、そこから HTML 文書に object タグを自動生成して埋め込むようなもの）ではＮＧかもしれませんが、所詮は HTML なので、手書きなどで既定の書式の object タグを埋め込むことが出来れば特に問題はありません。

> その方向が強いですが、マネージコントロールであれば開発ツールがVS2005で統一できるという利点もありますね。

統一てか、C# 等で書いたモジュールを ActiveX コントロールから素直に呼び出したいのであれば、開発ツールは必然的に VS2005 (VC8) になります。

>>ロジックを Web サービスにしてサーバ側で処理を実行するようにして、それをブラウザから AJAX 的にスクリプトで非同期に呼び出すんでは駄目なのかな？
>
> 双方向イベント通知なので非同期は要求にはないですね。

Atras で言うところの Update Panel みたいなものとの組み合わせではどうでしょうか？という意味です＞非同期

引用返信 編集キー/

■5320 / inTopicNo.15)

　Re[14]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (324回)-(2007/07/10(Tue) 15:10:04)

> object タグの書式は、ActiveX コントロールを扱う場合と少し異なります。

参考になります。m(_ _)m

>>その方向が強いですが、マネージコントロールであれば開発ツールがVS2005で統一できるという利点もありますね。
>
> 統一てか、C# 等で書いたモジュールを ActiveX コントロールから素直に呼び出したいのであれば、開発ツールは必然的に VS2005 (VC8) になります。

実体DLLはおいといて、
その上っ面(ラッパ)が、マネージコントロール　or　ActiveX　という認識でいました。
なので、マネージコントロールの場合、実体DLLも含め全部VB.NETでできちゃうなぁと思ってましたが違うのでしょうか？

> Atras で言うところの Update Panel みたいなものとの組み合わせではどうでしょうか？という意味です＞非同期

#参考になります。一応近未来バージョンですね。時期的につらいかも。
これはイベント待機・受信にからむ実装方法のひとつの例ですよね？
実体DLLが通信するのはサーバー常駐の別コンポーネントなのでWebサービス等にはできないです。
#というか今気がつきましたが、ひどりさんはWebサーバーとの通信ということで書かれていますよね？

引用返信 編集キー/

■5322 / inTopicNo.16)

　Re[15]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ 中博俊 (1114回)-(2007/07/10(Tue) 16:00:16)

Atlasてな古い名を

ASP.NET Ajax Extensionは半年くらい前にリリース済みです。.

引用返信 編集キー/

■5329 / inTopicNo.17)

　Re[16]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (325回)-(2007/07/10(Tue) 18:02:37)

> Atlasてな古い名を
> ASP.NET Ajax Extensionは半年くらい前にリリース済みです。

atrasで検索
もしかして atlas を選択
で、お、これかと思ったページを見る
そこには「ASP.NET 将来のバージョン」と書いてありました。
atlas=Microsoftと思っていなかったゆえの結果でした。。。

引用返信 編集キー/

■5331 / inTopicNo.18)

　Re[15]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ 渋木宏明(ひどり) (272回)-(2007/07/10(Tue) 18:12:41)

> なので、マネージコントロールの場合、実体DLLも含め全部VB.NETでできちゃうなぁと思ってましたが違うのでしょうか？

マネージコントロールなら C# でも VB でもお好きな .NET 対応言語でどうぞ。

もどきでない、「がわ」役の ActiveX コントロールの開発に「VS2005 が使用できない」という記述がみられたので、「VS2005（に含まれる VC8）で開発可能である」と指摘しただけです。

> これはイベント待機・受信にからむ実装方法のひとつの例ですよね？

と言ってもいいでしょうね。
クライアント主体で自発的な通信を開始するためのパターンのひとつです。

> #というか今気がつきましたが、ひどりさんはWebサーバーとの通信ということで書かれていますよね？

そです。で、Ｗｅｂサーバ側で本来の通信先？と通信すればよいのではないかと。

引用返信 編集キー/

■5339 / inTopicNo.19)

　Re[16]: ブラウザとローカルコンポーネントの連携

▲▼■

□投稿者/ まどか (327回)-(2007/07/10(Tue) 23:00:30)

■No5331 (渋木宏明(ひどり) さん) に返信
>>なので、マネージコントロールの場合、実体DLLも含め全部VB.NETでできちゃうなぁと思ってましたが違うのでしょうか？
>
> マネージコントロールなら C# でも VB でもお好きな .NET 対応言語でどうぞ。
>
> もどきでない、「がわ」役の ActiveX コントロールの開発に「VS2005 が使用できない」という記述がみられたので、「VS2005（に含まれる VC8）で開発可能である」と指摘しただけです。
>
>>これはイベント待機・受信にからむ実装方法のひとつの例ですよね？
>
> と言ってもいいでしょうね。
> クライアント主体で自発的な通信を開始するためのパターンのひとつです。
>
>>#というか今気がつきましたが、ひどりさんはWebサーバーとの通信ということで書かれていますよね？
>
> そです。で、Ｗｅｂサーバ側で本来の通信先？と通信すればよいのではないかと。

解決済み

引用返信 編集キー/

■5340 / inTopicNo.20)

　Re[17]: ブラウザとローカルコンポーネントの連携

▲　■

□投稿者/ まどか (328回)-(2007/07/10(Tue) 23:02:30)

#送信失敗

>>そです。で、Ｗｅｂサーバ側で本来の通信先？と通信すればよいのではないかと。

なるほど。それは思い浮かびませんでした。
検討してみます。

おかげさまで取っ掛かりの土台としてだいぶ見えてきました。
みなさま長々とありがとうございました。

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -