外部ファイルアクセスを伴うライブラリとASP.NET
ASP.NETの話です。
ASP.NETのプロジェクトから、直接サーバーのローカルファイルにアクセスできないのは、Webアプリケーションを組んでいれば、大体予想がつきますよね。
でも、それがライブラリ、しかも自分の作ったものではないライブラリだと、なかなか気が付きにくい場合があります。
ミドルウェアにアクセスするためのライブラリを使ったプロジェクトが最近あったのですが、どうしてもASP.NETのWebサービスから、そのミドルウェアにアクセスしようとするとエラーが発生する、という事態になりました。
エラーが出る時と出ない時があり、エラーになると、再起動しようがなにしようが直らない。
そのDLLから飛んでくる例外のメッセージをみると、「キャッシュにアクセスできない」という感じの内容です。
さて、キャッシュってなんじゃらほい、と調べてみると、そのライブラリが独自のフォルダを用意して、キャッシュしていることが分かりました。
そして、そのライブラリをインストールする際に、インストーラー内でミドルウェアへのテスト接続を実行すると、あとで必ずWebサービス側がうまく動かなくなることが分かってきました。
１）テスト接続をすると、インストーラーが「インストーラー実行者の権限」でキャッシュファイルを作成する。
２）ASP.NETのワーカープロセスは組み込みIDであるNetworkServiceでDLLを実行するので、１）で作成されたキャッシュファイルにはアクセスできない
３）さようなら
と、こんな流れになっていたのです。
ちなみに解決策は、ワーカープロセスのアカウントを別のローカルユーザーアカウントに変更することです。
もちろんそのローカルユーザーは、IISのワーカープロセスグループに所属させなければいけません。
このエントリで大事なことは「ASP.NETからライブラリを使うときは、そのDLLがどんなファイル操作をするかを把握しておかないと痛い目をみるよ」ということです。
ちなみに、このミドルウェアとはEMC社の文書管理サーバー「Documentum」。
EMC社のユーザーグループのBBSに書こうかと思いましたが、アカウントもないし英語で書くのもイヤなので、こっちに書きました。
日本語のできないプログラマーの方、頑張ってください。
WPF開発やります
めっさお久しぶりです。
やっと会社での仕事も一段落し、勉強する時間もとれるようになってきました。
現在の会社に入ってから3年目に突入しましたが、久々に過去の自分のブログを読んで、コーディングが乱れ切っているのを実感しています。
その主な原因が、OfficePIAとAcrobat SDKにあることは否めません。
OfficePIAとは、Microsoft OfficeをC#で制御可能にするCOMのIACで、要するにVBAでできることをC#でやれます。
これを使ってWordを外部からゴニョゴニョするわけですが、なかなかどうしてハイブロウなバグがいくつも出てきます。
Word2003のころはまだよかったのですが、Word2010に移植したら、メモリリーク。それもWord側で。
いろいろ探っていくと、ループするだけでメモリ使用量が増えていく。タスクマネージャーを見ながら、どこで漏れているのかを類推していく以外にデバッグ方法がありません。そうやって、メモリリークしない方法で書いていくわけです。ソースの可読性もクソもありません。他にも、印刷すると落ちてしまったり、画面と印刷結果があっていなかったり。ソースを寄こせといくら叫んでもM○に届くはずもありません。なのにWord2013とか、やめてくださいマジでもう。
Acrobat SDKは、上に比べるとなかなかよくできています。ただ、いかんせん言語がCな上に、プラグインにするとエントリポイントがAcrobat側になってしまったりして、使い勝手がよくありません。最近、SDKの一部の機能がサロゲートペアに対応していないことが判明して、頭を抱えています。自分の担当じゃないですが。
これらの要素技術をまとめる上で、.NETというのはなかなかよくできています。
結構なんでも連携できるし、デザインパターンを駆使することで、ある程度ソースの見栄えもよくなりました。
で、まあ、そろそろ次の段階に進もうか、ということで、やっと.NET3.5です。
（4.0？それ何のお菓子ですか？）
WPFですが、専門書籍を探すのに苦労しました。
茨城の片田舎から東京まで出て、見つかったのがたったの2冊。
「WPFなんて、見たらだいたいわかるんじゃね？仮にもFlex使いでしょ？」と言われそうですが、まあその通りです。
ですが、新しいフレームワークを使うときには、大抵新しいプログラミングパターンも同時に覚えることになります。
WPFでいえば、MVVMパターンがそれにあたります。
ViewModelという、いってみればそのビュー（フォーム）専用の、イベント処理やらなにやらをロジックとプロパティとともにまとめた小さなモデルを用意してやって、そこである程度整理されたデータを上位のモデル（MVCでいうところのモデル）に渡します。WindowsFormでも採用できるスタイルではあるのですが、WPFでは半ば強制です。
ボタンを押したときのイベントも、直接コマンドパターンのコマンドオブジェクトとバインディングできるというかバインディングしやがれテメエみたいな作りになっていて、ようするに「コードビハインドになんか余計なことを書いたらコロス」というスタイルになっています。
こういうスタイルの押し付けは奇麗なコーディングをするうえで気持ちいい一方で、イレギュラーなことをするときには結構困ったりします。そのためにも、本格的にコーディングする前に、じっくり調査しておかないといけないのでした。
もうひとつ勉強しているのが、SharePointです。
これは既存のサーバーソリューションとの連携ができるかどうかの調査、という位置づけです。
相変わらずサーバー製品にはアレルギーがあるのですが、TechNetから落としてきてインストールしてみて、初めて「あ、これって結局CMSだったのか」と気付いたというマヌケさ・・・。個人的には、こういうもので製品を作ると、際限なく仕様変更や要望が入るので、ささっと作ったらとっとと離脱したいです。人生は短い。
そんなわけで、学習メモを再開していきたいと思います。
たまにアフィとか貼るかもしれません。最近250円ほど入ったようなので。
Windowの位置とサイズの保存
めっさお久しぶりです。
最近、やっと新しい職場でもプログラミングに集中できるようになりまして（というかプログラマが自分しかいないというか）、C#にもそれなりに慣れてきたので、久々に更新してみようかと。
設計を担当している同僚に「ウィンドウの位置とサイズを保存するようにして。確か、ネットに簡単な方法が書いてあったから」と言われて、調べてみたのが@ITのこの記事。
.NET TIPS
Windowsアプリケーションの位置やサイズを保存するには？［2.0のみ、C#、VB］
http://www.atmarkit.co.jp/fdotnet/dotnettips/438winsettings/winsettings.html
で、早速実装したところ、ものすごく挙動不審。
問題１）バックグラウンドに隠れたら、復帰するときにはめっさ小さくなってる。
問題２）ウィンドウの右上をドラッグしてサイズ変更しようとすると、サイズが変更されずに移動する。
なんじゃコレと思い、さらにググってみると、案の定できないと苦労している人が。
Properties.Settingsでのフォーム状態保存で、挙動不審
http://dobon.net/vb/bbs/log3-29/17479.html
なにやらいろいろ頑張っておられるので、サクッとコピペして試してみたところ、問題１はクリアできていたけど、問題２は残ったまま。
で、ちょっと冷静になって考えてみる。
・・・ん？
そもそも、これってバインディングする必要あんのか？
えーと、Properties.Settings.Defaultに、保存するプロパティを追加するのはアプリケーションの「設定」タブからできるよね？
で、FormClosingイベントで保存してる。
もしかして、
１）FormClosingで（WindowStateをNormalに戻したうえで）BoundsプロパティをProperties.Settings.Defaultに代入して保存する
２）FormLoadイベントでProperties.Settings.Defaultから読みだして、Boundsにセットし直す
ってだけでいいんじゃないか？
結果。
あっさりできました。
今回のエントリは、この問題でさんざんググって困っている人のために書きました。
おしまい。
RIAに冷水を浴びせるGumblerウイルス
新しい職場での仕事が忙しくて、Flexもしばらくいじっていないのですが…。
年末年始にかけて、新型インフルエンザ並みに猛威をふるっているGumbler(GENO)ウイルス。
会社の人からも注意喚起のメールが来ました。
このウイルスの特徴は、JavaScriptとの連携ができるブラウザプラグインの脆弱性を狙っている点。
Adobe reader, Flash Player, Javaなどの複数のプラグインを標的にしています。
そして、もうひとつの特徴はWebごしでウイルスが次々に改変される点。
セキュリティで考えると決して万全とは言えないRIAの動作基盤の信頼性を、ボロボロにする破壊力を秘めています。
その昔、ActiveXがセキュリティでがんじがらめにされてネット上での存在価値を失ってしまったように、RIAの自由度を低く押さえつけてしまうことになるかも知れません。
そうでなくとも、RIAの企業への導入のハードルは高くなるでしょう。
RIAへの置き換えが今の企業向けシステムの開発需要を支えているのだとすると、ITの景気回復はさらに遠ざかってしまうかもしれません。
まあ、自分それどころじゃないんですけれども。
Office2003 Professionalがインストールできない
久しぶりに書くのがプログラミングの話でなくてすみません。
Windows7のファミリーパックを買って、Macとデスクトップのアップグレードを行いました。
その後、Office2003Professionalをインストールしようとしたら、X2561403.CABが見つからないとかでインストールが進行しません。
LISTool.exeとかでMSOCacheディレクトリを構築すればインストールできるはずと思っていろいろやりましたが、一度はインストールを完了させないと、このアプリケーションは結局利用できません。
足りないCABだけでもインストール途中で追加してやれば・・・とも思いましたが、途中から挿入しても消えてしまいます。
仕方がないのでMSに問い合わせようとも思いましたが、すでにOffice2003は有料サポート。
Windows7ならサポート範囲内ですが、MSからはやっぱり「これはOfficeの質問ですよね？」との返事。
あんまりにも情報がないので、Office Personalならもしかしたらインストールできるのかとも考えてみたり。
ほかの人もインストール出来ていないなら、今頃ネット上では大騒ぎのはず・・・。
とりあえず、同じ問題でググってここにたどり着いた方、コメントをお願いします。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
2010/01/26 追記
ある日、WindowsUpdateを入れたらインストールできるようになりました。
なんだったのか・・・。
今日からASP.NET
【これまでのあらすじ】
日本がサハラ砂漠になったかのような気分で長すぎる夏休みをさまよい、在宅プログラマになりました。
えー、しばらく姿をくらませておりましたが、ブログを再開します。
とはいえ、しばらくFlexはお休み。転職したのに伴い、.Netプログラミングを久しぶりにやることになりました。
なんだか納期が短いので、必死でプロジェクトの設計書を読み下しつつ、C#とASP.NETのおさらいをしています。
もっとも、半分ぐらい家の掃除と模様替えだったりもしましたが･･･。
何しろ、広い作業机を入れないと仕事にならない。
ということで、IKEAから一生懸命机と本棚を買ってきて組み立てて、ダンボールゴミを燃えるゴミに出すために鋏でチョキチョキ･･･。実に地味な週末を過ごしました。
それにしても、気がつくとubuntuのデスクトップが2台、WinXPデスクトップが1台、ネットブック、MacBook、そして会社のPCの大所帯。
あまりにも無駄が多い（主に電気代）ので、Ubuntuは処分してNASに置き換えたいところです。
さて、久々にC#をみると、Javaよりも進んでいる、と言われるのがよくわかります。
特にデリゲート。委譲がAS3と同様にメソッド単位でできるし、マルチキャストも出来る。
気がつくとVisualStudioは2010が出るって話になってて、.net Frameworkも4.0が出るとか。
そのわりに技術書が少ない気がするし、Web上のリソースも（まだ探しなれてないからかもしれないけど）少ない。
外部デバイスもいじらず実行速度も気にならない程度のツールなら、AIRだと数倍早くできてしまうので、ともかく間口を広げてもらいたいものです。
ASP.NETも、昔見たときにはあまりよい印象を受けなかったけど、今見ると悪くないです。
今度の案件ではAjaxは使わないかな？と思っているけど、ちゃんとイベントを発するたびにリロードされるし、ロジックをクライアント側として（画面とペアで）書けるので、Strutsよりは快適。とはいえ、ビジネスロジックはちゃんと分けるべきなんだろう。もう少し研究しなきゃ。
国際化リソースがXML（*.resx）ってのは便利な反面、冗長で編集しにくいかも。
英語リソースを校正に出すことを考えると、IDE上でコンパイルってのはあまりやりたくない。
MFCの頃から思ってたけど、面倒くさいよね。
しかし、GridViewは便利だなぁ。
Flexでやってた時にもサーバー側のページングはLCDSで実現できてたけど、予算がなかったので全部クライアントでデータを抱え込んでページング、なんてことをやってました。
あの時実装したものがはじめから実装されてるのはうれしい。
逆に言えば、ASP.NETから来た人がFlexのDataGridをその感覚でいじったら、そりゃキレても仕方ないですｗ
今日の作業では、ODBCドライバで接続したMySQLのDBスキーマをちゃんと読み込んでくれず、VSのビューからテーブルが見えなかった。MDBだと見えたりしたので、ドライバの問題なのかな。
ともかく、ASP.NETは目的引きリファレンスという本を読みながらやってて、今週中になんとか不自由なくコーディングできるぐらいまで持っていけそうです。
あ、そうだ。Express Editionで一番困ったこと。
MSDNがオンラインしかない。ヘルプはすばやく検索できないとヤダ！
