ClickOnce version Second（笑）
どうやら、ClickOnceは.NET Framework 4でversion. 2になるようだ。
Visual Studio 2010で、.NET Framework 2.0向けのWindows Formと.NET Framework 4向けのWindows Formを発行してみよう。その上でマニフェストを比較してみると、スキーマが微妙に違うことが分かる。
一部のスキーマには「ClickOnce v2」なんて書かれているところもある。
うわぁ、出世したね（笑）
細かな定義はこちらを参照してください。
.NET Framework 4 ClickOnce (version 2)
<http://msdn.microsoft.com/ja-jp/library/k26e96zf(VS.100).aspx >
.NET Framework 2.0 ClickOnce (version 1)
<http://msdn.microsoft.com/ja-jp/library/k26e96zf(VS.90).aspx >
大きな違いはTargetFramewrok指定ができるようになったことかな。
ちなみに、.NET 2.0用のアプリケーションver.1.0を最初に作って、エンドユーザにこれを了承させておいて、次のver.1.1で.NET 4を参照するっていう技もできるみたい。
いいんかよ！
まぁ、これくらいだとそこまで悪用もできないと思うけど、勘違いで間違って発行とかしちゃったらトラブルになるかもねｗ運用の人、注意で！
ちなみに、この.NET 4用のマニフェストなんだけど、MageUI.exeで作れなくね？MageUI.exeちゃんは.NET 2.0用のマニフェスト前提で考えてるみたいだよ？RC版なのが悪いのかな？
ほむ。
詳しい差異は調べてみるつもり。Topicがあったらまた書きま。
Visual Studio 2010 Transact SQL 静的解析機能
次期 Visual Studio 2010のUltimate EditionおよびPremium Editionにはこれまで「Visual Studio Team System 2008 Database Edition」であれば利用できたけど、Edition違いで使えなかった機能がたくさん追加されている。
そのうちの1つ、Transact SQL 静的解析機能。
ルールの総数は11でまだまだ数は足りないように見えるけど、これまですげぇ能力ある人の聖域みたいになっていたStored Procedureにチェックをかけることができるのがうれしい。
ルールの詳細はこちら。
<http://msdn.microsoft.com/en-us/library/dd172133(v=VS.100).aspx >
この機能を利用するためには、まずデータベースプロジェクトにデータベース定義を取り込んでおく必要がある。このデータベース取り込み後にデータベースに登録したクエリはどうやらチェックの対象外になるようだ。また、SR0014なんかは「Create Tableクエリ」と「Insertクエリ」が両方ともプロジェクト内に取り込まれていないと発動しない模様。
利用したイメージはこんな感じ。
これはpubsデータベースを対象に静的解析をしたもので、pubsがSQL Server 2000用のデータベースサンプルであることから、いくつか互換性の警告が出ているのが分かる。まぁSQL Server 2008でSQL Server 2000用のデータベースを使ったらそりゃあ互換性の1つや2つ問題になるよね（笑）
この機能のいいところはVisual Studio 2005の開発案件なんかでも使えるところだと思う。というのも、ストアド、ビュー、トリガなど、「IDEで作るソースコードとは独立に扱うことができるもの」が、この機能の対象だからである。とりあえず静的解析してみようと思うなら、捨てマシンにVisual Studio 2010をインストールし、静的解析を実行してみて、その結果を反映させれば良い（注：ライセンスの問題はちゃんとクリアしてね）。SR0013など「明らかに不具合のもと」なんていうものを見つけることができるのも良いと思う。
これは効果の大きさはさほどでもないかも知れないが、既存スタイルに悪影響が無いという点で「アリな機能」だと思う。
ClickOnceプログラミング 其の六
ClickOnceプログラミング 其の六 HTTP圧縮を有効に利用するために
環境が手元にないので、ぱぱっと文字だけで書いちゃいますが、「わかんねーよ」ってことであればコメント欄にその旨書いてくださればお返事しますねー。
Windowsアプリケーションによるスマートクライアント型のアプリケーション開発をしていると、よく「配布の問題」に突き当たります。それも時期的に言うと、設計や開発とは異なるタイミングで･･･。しかもその問題には常に「自動更新の問題」がつきまといます。幸いClickOnceを利用していると、自動更新の問題は無視できるのですが、ネットワークトラフィックを介するために別の問題が発生します。それが、通信速度やサーバ負荷の問題となります。
今回のスタート地点はここから。
「自動更新の方法をどうするか？」については以前のエントリを参照ください。ただ、要件によっては別の技術を選択すべきこともありますのでご注意くださいませ。
さて、話を戻すと、ClickOnceを利用した場合、配布問題で要求事項に挙がるのは以下の2つ。
・どうにかして通信トラフィックは少なくしたい。
・どうにかしてサーバへの負荷は抑えたい。
通信トラフィックの軽減は差分ダウンロードでできますし、通信トラフィックの分散はダウンロードグループでできます。通信トラフィックが少なくなればサーバへの負荷はもちろん下がりますし、通信タイミングが分散されればサーバ負荷は限界を越えづらくなります。とはいえ、「どうしても通信しなければいけないファイル」は必ず存在し、このファイルが重いことだってあります。この必須ファイルにより発生する通信トラフィックをどのように「軽減」するか？
ここでは、この通信トラフィックの軽減策を説明し、ClickOnceアプリケーションの中身を一切変えずに速度を向上させ、負荷を軽減する方法を取り扱います。
ClickOnceアプリケーションは通信トラフィック量によってその速度が大きく変わります。要は通信トラフィックが少なければ速度は相対的に下がります。これを目的として利用するのがHTTP圧縮です。
一方で、経験の有る方ならここで2点の疑問点が浮上しているはずです。
1. サーバで通信トラフィックを圧縮する手間や負荷はバカにならない。
2. クライアントで圧縮ファイルを復元する負荷は無視できない。
2. クライアントで圧縮ファイルを復元する負荷は無視できない。
これはおっしゃる通り。1台しかないサーバ負荷と比較して複数あるクライアントに負荷を押し付ける方法は、クライアントの能力が高い場合は一つのソリューションなのですが、どーしようもないクライアントマシンだと逆に大変なことになってしまいます。過去にも実際に起動だけでも3分かかるマシンがあり、そのマシンでだけパフォーマンスの問題が発生したことがありました。しかし、HTTP圧縮は「クライアントが圧縮を要求するか？」をもとに通信圧縮するかどうかを決めるので、この場合は当該のマシンでだけHTTP圧縮を無効にしてしまえば良いです。
1. サーバで通信トラフィックを圧縮する手間や負荷はバカにならない。
これ、普通ならそうですよね。でもClickOnceは配布するモノ自体はクライアントが数万台居ても全て同じです。IISなどにあるHTTP圧縮機能は静的圧縮と動的圧縮の2つのモードをサポートしており、ClickOnceが利用すべきなのは静的圧縮です。この場合、サーバは1度だけ圧縮して、以降はこれを利用すれば良いことになります。この結果、HTTP圧縮をすることで、通信トラフィック量が減るにも関わらず、クライアントごとに圧縮する必要がなく、解凍はクライアント任せなので、サーバのCPU利用率が低下することになります。
ここまでは理論ですから、簡単だったと思います。じゃあどうやって実践するのか。実際に求められるのはここでしょう。ここからはIIS6.0とIIS7.0の2つの場合においてHTTP圧縮をする方法を簡単に説明します。
IIS6.0の場合
cscriptで調整します。ちなみにIIS6.0は拡張子でHTTP圧縮を決定するのでこういう感じ。
---
cscript.exe adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcFileExtensions "もとからあるやつ" "deploy"
---
HcScriptFileExtensionsは動的圧縮用なので、ここでは無視します。上述したようにIIS6.0は拡張子でHTTP圧縮するか否かを決定するので、deploy拡張子は絶対に使ったほうが楽です。これをしないと色々設定しなくちゃいけない上、他のアプリケーションと競合することもあってめんどくさいんです＠ｗ＠
ちなみに圧縮の方法はGZIPとDEFLATEの2種類があるけど、IEから通信する場合、GZIPだけやっておけばOK。もし環境や要件でDEFLATEもサポートする必要があれば上述のスクリプトのGZIPをDEFLATEに置き換えてもう一個流す必要があります。
確かHTTP圧縮自体を有効にする必要があったような気がしますが、IISマネージャのGUIから簡単に設定できたはずなのでここでは省略します。上述のスクリプトはcscriptじゃないと反応しなかったはず。
# Metabaseを直接編集するって手もあるけど、これ、色々めんどうですよ。IIS6.0はMetabaseドリブンじゃなくてメモリ上のデータドリブンだからｗ
ちなみに、これで終わりではないです。
IIS6.0上でHTTP圧縮が「何時」実施されるのか？
それは初回リクエスト発生時です。実はIIS6.0ではこの初回リクエスト時、圧縮を裏でするために非常に時間がかかります。このため、実運用時は運用担当者がとりあえず1回以上、通信を発生させておく必要があります。ダウンロードグループのファイルに対応する通信を発生させておくのをお忘れなくｗ
IIS7.0の場合
こちらは色々やり方がありますが、とりあえずappcmdでHTTP静的圧縮を有効にしちゃいましょう。あ、Windows Server 2008の場合はデフォルトでインストールされてないので圧縮機能の有効化を先に！
---
appcmd set config –section:urlCompression /doStaticCompression:true
---
もちろんIISマネージャでも有効にできますが、まぁどうせ画面を見せられないのでスルーします＾－＾；
圧縮できる影響範囲は以下のいずれかです。ただし、ファイルレベルでの圧縮はapplicationHost.configの直接編集が必要です。まぁあんまりファイル単位での設定とかしないですよね＾－＾
・サーバレベル
・アプリケーションレベル
・仮想ディレクトリレベル
・ファイルレベル
ではClickOnceのデプロイが適切にHTTP静的圧縮できるように設定しちゃいます。IIS7.0では拡張子での管理はしません。代わりにMIMEで圧縮是非を決定することになります。サーバレベルで設定する場合はapplicationHost.configを直接編集し、以下のようにdeployに対応するMIMEを追加します。ちなみにdeployに対応するMIMEはたぶん[application/octet-stream]だったと思いますが、間違ってたらイタイことになるので確認してください。
---
<httpCompression>
<dynamicTypes>省略</dynamicTypes>
<staticTypes>
<add mimeType="text/*" enabled="true" />
<add mimeType="message/*" enabled="true" />
<add mimeType="application/javascript" enabled="true" />
<add mimeType="application/octet-stream" enabled="true" />
<add mimeType="*/*" enabled="false" />
</staticTypes>
</httpCompression>
---
これで設定自体は終わり。とりあえずIISを再起動しておいてください。IIS7.0はやらなくても大丈夫だった気がするけど。
ちなみにこれで終わりではないです（笑）またかよ･･･
IIS7.0でHTTP静的圧縮を実施するタイミングはIIS6.0のそれとは全く異なり、以下となります。
同一のファイルに対して、一定時間内に一定数以上のアクセスがあったとき（既定：10秒間に2回以上）
ってことで、この既定の設定を変更していない場合はとりあえず運用担当者がプチ・アクセスラッシュをしてくださいｗ
ちなみにこの設定を変更するのは以下の2箇所です。
・system.webServer/serverRuntime/frequentHitThreshold（既定：2）
・system.webServer/serverRuntime/frequentHitTimePeriod（既定：00:00:10）
以上を設定しておくことによりHTTP静的圧縮を利用できるようになり、CPU利用率と通信トラフィックを削減できるようになります。しかもクライアントの設定次第でON/OFFを切り替えられるので、お勧め。
あ、テストのときにはクライアントのブラウザ設定で「HTTP1.1を利用する」にチェックを入れないとダメですよ。
よし、ClickOnce終わり！
正直、他に色々面白い技術が出てきて、早くそっち触りたくてしょうがなかったりするｗ