Hobby::.NETの最近のブログ記事

めずらしく開発ネタですよ。

System.Addin、
.NET Frameworkに用意されている、アプリケーションにアドインとかプラグイン機構を作りこむためのライブラリ。

System.Net.Sockets.Socketクラスには、ReceiveTimeoutというプロパティが存在する。

Receive開始から指定時間受信データが無いと例外を吐いてくれるらしい。
※この例外が必ずしも出るとは限らないみたいなのと他のと同じSocketExceptionで、困るのはまた別の話。

で、Socket作成して、プロパティ設定して・・・でOKだと思うのが普通。

しかし、このプロパティ、どうやら一度でもタイムアウトを発生してしまうと、0値扱いになるらしく、受信が即終了してしまうことになる。

つまり、タイムアウトをやりたければ、受信前には必ず設定しなきゃならんってことらしい。

多分送信も同じ。

であれば、メソッド呼び出しにタイムアウト値引数を取れるようにしておいて欲しいなって思う。

ってことで、仕事なんですが。

やっと開発案件なのですが。

.NET なのですが。

複数プロセスで連携とかやる羽目に陥っちゃうわけですよ。

ぶっちゃけ、なんでか分からんのですけどね。

マルチスレッドでえぇやん。ってのは本音。

で、プロセス間連携に、WCFを使うことを思い立つわけ。

主に名前付きパイプで実装してみるところまではできるんだけど、落とし穴がでかい。

ま、俺もよく知ってるわけじゃないから、認識を誤ってることがある可能性は否定できないのだが・・・

久しぶりに書く。

たとえばだ。
上書きインストールしたいけれど、実行ファイルがロックされている場合、次回起動時にファイル置換を予約して、再起動を促したりする。

でも、.NETなら、ShadowCopyFiles = "true" した AppDomainSetup を指定して作成した AppDomain を使用すれば、そのAppDomain 内では アセンブリのシャドウコピーが働いて、実行ファイルとかのロックが行われないようになる。

仮に実行ファイルを削除しても、動き続けるプロセスってのが実現できたりする。
※悪用できそうな気がしますが、そういう目的ではありません。

でも、ここであることに気づく。
ASP.NETの場合は、IISとかがAppDomainを用意してくれるからできている。
単体実行ファイルの場合はどうすんの？
さて。

次回があれば続く

とある合同勉強会で、Lチカを実施、なんとか点滅までできました。
＃位置バレしたくないので、伏せておきます。申し訳ない。

.NET Micro Frameworkってのがあるのを知ってはいたけど見たことはなかった件。

先月、これも別の某所で見る機会があり、興味が湧きまして。

FEZ Cerb40とかいうモジュールを購入。
＃これが先々週。

で、とりあえず、動かしてみるべ！ってことで、先駆者のお知恵を拝借しつつ、実施。

まず、これ、モジュールに足を生やさないといけない＞半田付けです。
ついでに、水晶振動子をつけるパターンもあるので、手持ちのものを付ける。

あとは、3.3Vが必要だという点。
秋月の3.3V 3端子レギュレータキットがいくつか残っているので、それを使って外部モジュールとして用意。

で、VisualStudioの準備。
一応、先駆者様サイトの手順でOKなんだけど、一つ注意。

ファーム書き換え時に使用する実行ファイルは、VC++2005のランタイムを必要とするので、インストールが必要でござる。
※「アプリケーションを正しく起動できませんでした (0xc0150002)。」とか言われる。

あとは、Lチカプログラムをコピペでうご・・・かない。

ってか、GHI.OSHW.Hardware.FEZCerberus.Pinが無い。
最新バージョンでは、GHI.Hardware.FEZCerb.Pinになってました。

とりあえず、動きますた。
作るのは、GadgeteerプロジェクトでもOKです。
＃Gadgeteer.Timerも使えるので、イベントドリブン(っぽい)プログラムが書けます。
当然、デバッグ時に、ブレークポイントも使えます。

まずは第一歩完了です。

Forms.Formでアプバーっぽくできたのは昔の話。

今度はWPF。
Forms.Formと同じでできると思ったら、できねぇでやんの。

WPFのListBoxとかでキーボード操作を想定したときに困るのが、Clickイベントが無いことだったりする。

でも、キー入力を確認してEnterキーなら処理を・・・なんてやるのは面倒だ。

正しいかどうか分からないが、埋め込みTwitterの取り込み処理と、そこからデータをDOM操作する処理を初回BackgroundWorkerでやってたのだが、BackgroundWorkerだとそのオブジェクトを生成するのに時間が掛かるらしい。
＃確かなことは分からないが、デフォルトドキュメントのカウンタログを見ると、/ と /index.htmlとの間に最大で5秒以上のタイムラグが発生しているらしい。

そこで、BackgroundWorkerをやめて、ThreadPoolを使うようにした。
すると、タイムラグは1秒以内に収まるようになった(今のところ)。

プール数とリクエスト数にも依存するかも知れないけれど、まずまずの結果かな？
これで問題が出なければ、今後、ThreadPoolを使える場所ではThreadPoolを使うことにしよう。

とりあえず、方法だけ書いておくか。

IIS用のマネージモジュールで、HTMLコンテンツに対し、カウンタと一緒に書き換えフィルタ処理を入れてある。
＃フィルタを使ったマネージモジュールの創り方は、ウィジェットのサイトカウンタって文字列をクリックな。

ただ、書き換え時にいちいちrssを取りに行くと、twitterサイトが重いときとか、回線混雑のときに応答待ちが大きくなるので、定期的にメモリ上に取り込むのを別途タイマーかけてやってる。

本当にちゃんと保持できてるかは未確認だけど、一応、シングルトンクラス内でタイマー使ってるから、保持できているはずだ。

保持したrss(XML)をごにょごにょ弄って書き換えるのは、いちいちやってる・・・のは無駄だな。
＃本当なら、保持するのは書き換えに必要な加工状態のものでいいはずだよなぁ・・・ま、いいか。

OverSsl Clientのコンセプトは良いはずだ。
暗号化で安全な通信経路を保障しちゃうのは結構ありがたいはずだ。
だが、問題はいくつかある。
＃STARTTLSに対応できないのはコンセプト上、仕方ないのだが。

一番の問題は、アプリケーションの設定を変更しなければならないことだ。
この変更に対応できない場合はとても残念なことだが利用できない。
例えばWWWブラウザなどはその最たるものだ。

そして、それは、サーバーを固定指定することに起因する。
OverSsl Serverの場合は、この仕様で問題ないのだが、Clientでは問題となるわけだ。

他にも問題はあるのだけれど、この問題が解消できると、クライアントアプリケーションの設定を不要にできる可能性が出てくる。
つまり、あまりネットワークを知らない一般ユーザでも導入が簡単になる可能性がある。