カテゴリー: Tech

複数サイトを持つIISへのASP.NETプロジェクトのデプロイ

/ (･∀･) / コメントする


FIX: ホスト ヘッダーまたは IP アドレスを Visual Studio 2003 または
Visual Studio 2002 Service Pack 1 に使用すると、 Web サイトに
Web Setup プロジェクトは展開できません。

複数サイトを持つIISに素のWebセットアッププロジェクトを
インストールしようとすると、サイトの指定が出来なくて
上手く動かない件なのだが、
機械翻訳の日本語だとなんのこっちゃわからん。

要は
　1.[DPCA.msi package]をダウンロードして展開
　2.展開されたDCPA.dllをVisualStudioのそれと置き換える
　3.セットアッププロジェクトをビルドし、出来たmsiファイル名を引数として
　　　EnableHostHeaders.jsに与えて実行。
ということらしい。

混乱したのが

　”You must run the EnableHostHeaders.js script file.
　　This script accepts the
　　.msi file as its command-line parameter.”
　　　　↓
　「EnableHostHeaders.js スクリプト ファイルを実行する必要があります。
　　このスクリプトは、コマンド ライン パラメータとしてそのまま、
　　.msi ファイルを使います。」

acceptsのあたりが微妙だ。セットアッププロジェクト中のカスタム動作でやるかと思った。
スクリプトの内容を見たら違ってた。ちくしょう薔薇水機械翻訳め。

しかし、同一”マシン”上で複数アプリケーションのインストールが出来ないのは
相変わらず…
アプリケーションのフォルダをコピーするしかないのか。

SQLServer 2005

/ (･∀･) / コメントする

ちょっと触ってみた。と、言ってもほんの触りだけ。

昔作ったWindows 2003 Serverにインストールしようとしたのだが、
インストールにWindows Installer3.1が必要だったり、MDAC2.8が
必要だったりしてちょっと手間取った。が、とりあえず動く所まではやった。

ユーザーとスキーマの考え方が、SQLServer 2000から少し変わっていた。
2000は
　スキーマ = ユーザー
という感じだったが、2005からは
　スキーマ = 名前空間
という感じ。
明示的にスキーマ.テーブル名とかしてあげないとSQLが動かん。
今まで書いていたSQLがそのまま通らない、なんてことがあるかも。

これについては、既定のスキーマを設定してあげれば動作するので
大した話ではないが、稼働中のSQLServerの移行などのポリシーで、
既定のスキーマが使えないとかなっているとコード書き直し、とかになったりする予感。
まぁ、無いだろうけど。

あと、SQLServer 2005をインストールすると、Framework 2.0もインストール
されるので、コード側もいろいろ出来ることが増えそう。

とりあえず、まぁそんな感じ。

Nhibernateその後でOODBとか

/ (･∀･) / コメントする

NHibernateは複数キーの定義の扱いが微妙なのと、
パーシステントクラスのメンテナンスが煩瑣になりそうなので、
ひとまず今回の実装からは外すことにした。
いつもどおりADO.NETでいくことに。

しかし、ただ転ぶのも嫌なので、データバインドを極める感じで行こうと思う。
とりあえずMSDNの関連しそうなところを読む。

こんなことばかりやってるから、「お前のコードは他の人が理解できねぇ」
とか言われたりするが、僕はマニュアルに書いてあることしかやってない。
変なロジックも入れないし、設計やコーディング規約からも外れない。
マニュアル読まない君らが悪いんじゃ(ﾟＡﾟ)
いいから横へ来て座れ。そして共にコードを書く。それで解決だ。

それはさておき、今回Hibernateを触ってみて思ったのだが､
はたして、O/R Mappingは今後主流になるんだろうか。
過渡的な技術といえばそれまでだが､いい加減ＯＯＰＬからＳＱＬベースでの
データ操作もめんどい。

そんなわけで、最近はわりとＯＯＤＢとかＯＤＢに手を出しているわけだが、
ObjectStoreやCaché なんかの言語とのバインディングだけで
データ操作できてしまうあの楽さを味わってしまうとなかなかＳＱＬを
書く気にならなかったり。

そういえば、この前のCaché絡みの案件は結局流れてしまったなぁ。
.NETとの言語バインドが出来ていないとか、作る人たちがついてこれないとか、
そんな理由だった気がするが。
確かに集合をベースとして扱うのRDBに対して Caché なんかのOODBは
タイプ(クラス)ベースで物事を扱うので、RDBに慣れているエンジニアは
とっつきづらいのかもしれない。
ちなみに、この辺の考え方の対比のレベルが合っているかは謎。

ＯＤＢ使いたいなぁ。速くていいＤＢなんだけどな。
そんな感じで。

NHibernate

/ (･∀･) / コメントする

格闘中。熱血マッピングランド。

が、レガシーシステムからの移行なので、エンティティのidentifierを取らずに
そのまま移行したテーブルばっかり。
しかも異様に項目数が多い。正規化されてない。スキーマがVSAMから丸写し。

過去幾多のレガシー移行を見てきたが、これはもう定番中の定番パターン。
そして実装者がｳﾎﾞｧｰ。
普通にO/R Mapperが使えない。もうね、設計者いい加減にしろと。
まぁ、設計者自体居なかったりしますが。

今回は規模が小さいからどうにでもなろうが、このパターンで数億の
損失を毎回出してたりするところもあるとか風のうわさで聞いたことがある。
知っているのか雷電。知らんよ。

そんなことはどうでもいいので、とりあえず、meny-to-oneの扱いと
composit-keyをどうするかだけ解決すればどうにかなりそうなので
もう少し足掻いてみることにする。

げ。composit-keyはEquals()とGetHashCode()実装必須ですかそうですか。
パーシステントクラス作り直しじゃん(‘A`)

まぁ、例によって例のごとく僕は事前察知でヤバい所を
全力回避で責任を取りませんしー(･∀･)ｳﾌﾌ