ClickOnceアプリを公開するには単にWebサーバにアップすればよい!? 運用に失敗しないために注意すべき、5つの重要ポイントを説明する。
前々回および前回は、ClickOnceテクノロジを拡張・カスタマイズするための開発手法を説明した。今回は開発フェイズから運用フェイズに話題を移し、ClickOnceアプリケーション(以降、ClickOnceアプリ)を実際に運用する際に注意すべき5つのポイントを紹介する。
ClickOnceはWebサーバを選ばない。つまり、Windows上のIIS(インターネット・インフォメーション・サービス)によるWebサーバだけでなく、Linux上のApacheによるWebサーバなどに対しても、ClickOnceアプリを配置できるのだ(これは、ClickOnceがサーバサイド・テクノロジではなく、クライアントサイド・テクノロジだからである)。
実際にClickOnceアプリを各種Webサーバへ配置するには、単に「発行されたClickOnceアプリのディレクトリやファイル群」をコピーするだけでよい。
●MIMEタイプの設定
ただし、ClickOnceテクノロジを適切に機能させるためには、(基本的に)事前にWebサーバ上で、次の表で示す「ClickOnce関連の拡張子(.application、.manifestおよび.deploy)に対するMIMEタイプの設定」を行っておかなければならない。
拡張子 | MIMEタイプ |
---|---|
.application | application/x-ms-application |
.manifest | application/x-ms-manifest |
.deploy | application/octet-stream |
Webサーバで行う「ClickOnce関連の拡張子に対するMIMEタイプの設定」 「.application」は配置マニフェストのための拡張子、「.manifest」はアプリケーション・マニフェストのための拡張子、「.deploy」はClickOnceでクライアント環境に配布するファイルに付加される拡張子である。詳しくは「第2回 ClickOnceの仕組みを理解しよう」を参照してほしい。 |
このMIMEタイプの設定を行わない場合、IE(Microsoft Internet Explorer)で表示されたWebページ上のハイパーリンクをクリックしてClickOnceアプリを起動しようとしても、XMLの内容が表示されてしまったり(これが起こるのは主に拡張子「.application」のMIMEタイプが「text/xml」になっている場合)、[実行/名前を付けて保存]ダイアログが表示されてしまったり(主に拡張子「.application」のMIMEタイプが「application/octet-stream」になっている場合)することがある(※なお、.NET Framework 2.0がインストールされたWindows上のIISでは、これらの設定をしなくても問題なく動作するケースもある)。よってMIMEタイプの設定は極力行った方がよい。
実際にIISでMIMEタイプを設定するには、次の画面の手順を参考にしてほしい(Windows Server 2003上のIIS 6.0の場合)。
[コントロール パネル]の([パフォーマンスとメンテナンス]分野の)[管理ツール]を開き、そこから[インターネット インフォメーション サービス]を起動する。
(1)Webサーバのコンピュータの項目を右クリックしてコンテキスト・メニューを表示し、そこから[プロパティ]を選択する。
(2)表示された[<Webサーバのコンピュータの項目名>のプロパティ]ダイアログ上の[MIME の種類]ボタンをクリックする。
(3)表示された[MIME の種類]ダイアログ上の[新規作成]ボタンをクリックする。
(4)拡張子名(この例では「.application」)を入力する。
(5)MIMEタイプ(この例では「application/x-ms-application」)を入力する。
(6)以降、[OK]ボタンをクリックしていき、設定情報を保存すれば完了だ。
この例では「.application」拡張子に対するMIMEタイプの設定の例しか示していないが、当然ながら同様の処理を「.manifest」や「.deploy」という拡張子にも施す必要がある。
またApacheでMIMEタイプを設定するには、次のようなMIMEタイプの設定を、Webサーバ全体の構成ファイルである「httpd.conf」やディレクトリごとの「.htaccess」に書き込めばよい。
AddType application/x-ms-application .application
AddType application/x-ms-manifest .manifest
AddType application/octet-stream .deploy
●MIMEタイプの確認
最後に設定したMIMEタイプが正常に働いているかをチェックしてみよう。これを行うには、Webサーバとの通信データのやりとりをモニタリングし、HTTPレスポンス・ヘッダの「Content-Type」を参照すればよい。
HTTP通信をモニタリングするには、マイクロソフトが提供する「Fiddler」というツールがお勧めだ(Fiddlerについては「Windows TIPS:Webアクセスをモニタする」を参照されたい)。次の画面は、実際にFiddlerを使って.applicationファイルのMIMEタイプを確認しているところ。
【コラム】MIMEタイプが正しく受信できない場合
WebサーバのMIMEタイプを正しく設定したにもかかわらず、クライアント側でそのMIMEタイプを受信できていないように見える場合は、いったんクライアント・サイドのIEのキャッシュをクリアしてみると、その問題が解決されることがある。IEでは、WebサーバからMIMEタイプの通知を受けても、同じURLのWebページがキャッシュに存在すれば、そこに保存されているMIMEタイプの設定を優先させるという仕様になっている。従って、そのキャッシュをクリアすることで、新しいMIMEタイプの設定を有効化できることがあるのだ。
●利用可能なWebサーバの機能
○HTTPSプロトコルやファイル共有のサポート
ClickOnceは、HTTPプロトコル(http://〜)だけでなく、SSLに対応したHTTPSプロトコル(https://〜)、さらにWindowsによるファイル共有(file://〜)をサポートしている。ちなみにFTPプロトコル(ftp://〜)はサポートしていない。
○HTTP圧縮のサポート
ClickOnceは、HTTP圧縮をサポートしている。HTTP圧縮とは、GZIPアルゴリズムにより通信データを圧縮するテクノロジである(HTTP/1.1プロトコルで規定されている機能)。このようなHTTP圧縮が役立つのは、特にネットワーク帯域幅が狭い場合である(より速くアプリケーションをダウンロードできるようになる)。
例えば筆者の環境では、「5263」bytesの.applicationファイルをHTTP圧縮した場合、そのサイズは「1932」(37%)にまで縮小されたが、このようにして通信データ(ネットワーク・トラフィック)を少なくすれば特に細い回線でネックとなるファイルのダウンロード時間を軽減して、展開のパフォーマンスを向上できるはずだ。
ClickOnceでは通信データがHTTP圧縮されている場合、開発者が何もしなくても自動的に解凍してくれる。運用管理者(もしくは開発者)の作業はただ、ClickOnceアプリのファイル群の通信がHTTP圧縮されるように、Webサーバ上の設定を行うだけだ。この作業をIISに対して自動的に行うサンプルのバッチ・ファイルを用意したので、興味がある読者は参考にしてほしい(HTTP圧縮の設定方法に関しては「.NET TIPS:HTTP圧縮を使用してWebページを取得するには?」の「【コラム】Windows ServerのIISでのHTTP圧縮の設定」を参考にされたい)。
ただしHTTP圧縮が設定できるIISは、サーバ版OS(Windows Server 2003/2000 Server/NT Server 4.0)のものだけである。Windows XP Professionalなどに付属するIISはHTTP圧縮ができないように機能制限されているので注意が必要だ(参考:「Windows TIPS:Professional版に付属するIISの制限」)。
なお、ClickOnceでHTTP圧縮を利用するには、HTTPレスポンス・ヘッダの「Content-Encoding」に必ず「gzip」が含まれていなければならない(「Content-Encoding」の内容は、前述のFiddlerを使って、MIMEタイプとほぼ同じ手順で確認できる)。というのもClickOnceでは、「Accept-Encoding: gzip」を設定したHTTPリクエスト・ヘッダをWebサーバに送信する。そのため、WebサーバのHTTP圧縮の設定で「gzip」が含まれていない場合(例えば「deflate」のみが設定されている場合)はHTTP圧縮が行われないのである(ちなみにIISで通常どおりHTTP圧縮を設定すれば、「gzip」は含まれるはずだ)。
●利用不可能なWebサーバの機能
○Windows認証以外はサポートされない
ClickOnceでは、Windows認証しかサポートされていない。つまり、例えば次のような認証方法は利用できないということだ。
*1 サポート・オンラインの情報によると、プロキシ認証が利用できないのはバグのようで、.NET Framework 2.0の次のService Packで修正されるらしい。
Windows認証が使える環境なら、次の記事が参考になるだろう。
Windows認証が使えない場合、独自の認証処理を実装するしかないだろう。例えば「ClickOnceアプリが起動した後でWebサービスによる認証を実施すること」などが考えられる。
Copyright© Digital Advantage Corp. All Rights Reserved.