IIS7 用で SSL のテストをする場合のサーバ証明書

IIS7 で SSL のテストをする場合に、サーバ証明書が必要になります。

とりあえずテストしたい場合には、SelfSSL7 を使うと便利です。

IIS 開発チームの Program Manager のブログに、

SelfSSL7

が記載されていました。

テスト用に１か月だけサーバ証明書が利用できるようです。

Web Client Software Factory でコンテキスト・エラー発生

Web Client Software Factory なるものを知り、いろいろ実験中です。

試しにサブフォルダが２つあるサイトを作ってコンパイル実行してみたところ、VisualStudio 2008 の中でデバックしている場合には正常に動作しましたが、IIS のフォルダに配置して、単独で実行したところコンテキスト・エラーが発生して動作しませんでした。

原因は、Web Client Software Factory が IIS のアプリケーション・プールでクラシックモードを必要としているためとわかりました。

IIS のアプリケーション・プールでは、統合モードと、クラシックモードが設定できますが、統合型が IIS と ASP.NET の要求処理パイプラインを１つにしているのに対して、クラシックモードは、それぞれの要求処理パイプラインを別々に処理しているそうです。クラシックモードは、統合型で動作しない場合に使用するようにとありますので、若干効率悪そうに聞こえますね。

テスト用にWebサイト証明書を作成する

IIS でWeb サイトを運用していて、SSL を利用したいと思っても、いきなり証明書を購入する必要はありません。

IIS Resource Kit に含まれる selfssl.exe を使えば、１週間だけ利用できる証明書を作成することができます。

プログラムをテストして実際に利用開始するときに、本物の証明書を購入すればいいはずです。

この件に関して詳しくは、テスト用にサーバ証明書を自己発行する を参照してください。

32bit OCX を、64bitOS へインストール

32bit OCX を 64bitOS へインストールできない問題で次の２点に注意したところ、無事移植できました。

Q1）regsvr32.exe を実行したところ、権限エラーで 32bit OCX が 64bitOS へ登録できなかった。

A1）cmd.exe を管理者権限で起動すれば、regsvr32 での権限エラーは発生せずに OCX を無事登録できる。

Q2) VisualStudio でコンパイルした .Net アプリが、上記 32bit OCX を、64bitOS 上で正しく呼び出すことができない。

A2) コンパイルオプションで、ターゲットマシンが ANY になっている場合、32bitOS でも 64bitOS でも動作するコードが出力されます。この実行モジュールを 64bitOS 上で実行すると、64bit プログラムとして実行され、OCX を呼び出す際に 64bit OCX であると仮定するようで、これがエラーを引き起こしているようです。

コンパイルターゲットを 32bit (X86) に限定すると、実行モジュールは、64bitOS 上で、32bit プログラムとして実行するので、OCX も32bitOCX として呼び出すので、呼び出し成功します。

太陽の黒点数

太陽の黒点数と人間の経済活動が関係があるという記事を読んだことがあります。

太陽の黒点数は、National Geophysical Data Center (NGDC) で公開されています。

以下は、1800 年から現在までの月別黒点数のグラフ

MouseWheel イベントが複数回入ってしまう

Silverlight3 で、MouseWheel に対応するアプリケーションを開発中におかしな現象を見つけました。

Windows 上の IE, Chrome, Safari では正しく処理するのに、Firefox だけは、MouseWHeel イベントが複数回入ってしまうという現象に悩まされました。

いろいろ調べて、次のように e.Handled = true とすると複数回イベントを回避できることがわかりました。

Private Sub MainPage_MouseWheel(ByVal sender As Object, ByVal e As System.Windows.Input.MouseWheelEventArgs) Handles Me.MouseWheel

' ...
e.Handled = True 'To avoid multiple events.
' ...

IIS で FTP サーバにアカウントを設定する

IIS で FTP サーバを設定する際、ＦＴＰユーザごとに個別のフォルダを割り当てたい場合があります。

これは、FTP のデフォルトルートフォルダの下に、ユーザ名と同じ名前の仮想フォルダを与えることで実現可能です。

ＦＴＰのルートフォルダは、通常 C:\inetsub\ftproot\ がルートフォルダとして使用されます。

次図のように、仮想フォルダを UserA, UserB のように与えて、それぞれのプロパティで、物理フォルダを任意の位置に与えると、FTP でログインした際に、各フォルダの下をアクセスするようになります。

個別に書き込み権限を与えておけば、各ユーザから送信されてきたファイルを別々のフォルダに保存することができるようになります。詳細は、「FTPサーバでユーザー・フォルダを分離する（基本編）」を参照のこと。

GrADS フォーマットの注意点

GrADS （グラッヅ）ファイルは、GRID 配列型のデータの保存フォーマットとして使われるケースが多いようですが、そのファイル内のデータの並びには、少々注意が必要です。

Bitmap などのGRID 型データは、左上から右方向にデータを並べていき、右端まで行ったら、次に１つしたの行を同様に左から右へ並べ、右下に到達するまでこの処理を繰り返していきます。

GrADS ファイルは、左下から右方向にデータを並べて、右端まできたら、１つ上に移り右から左方向にデータを並べます。最後のデータは右上になっています。

このデータ配列について、詳しくは、GrADS online document を参照してください。

Webサービスをリモートからテストする場合

Webサービスをリモートからテストする場合に、次のようなメッセージが表示されます。

「テスト フォームは、ローカル コンピュータからの要求に対してのみ使用できます。」

これは、デフォルトで、HTTP GET と HTTP POSTが無効になるからで、web.config に次のように設定すると、リモートでもWebサービスをテストできるようになります。

<configuration>
    <system.web>
    <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>
    </system.web>
</configuration>

XBAP を完全信頼の元で実行するには

WPF プログラムを作成し、XBAP 形式でインターネットで配布しても部分信頼で動かすことになります。部分信頼とは、サンドボックス内でしか動けないという意味で、多くのヘビーなアプリケーションでは十分ではないでしょう。

証明書を付けて、クライアント側に証明書をインストールしてもらえば、完全信頼で動かすことができるそうです。クライアントに、そのサイトを承認してもらったことになるので、完全信頼で動かすことができるのでしょう。

手順については、

「XBAP を完全信頼で実行させる方法」を参照のこと。

テスト環境で XBAP を完全信頼で動かすには、クライアントの「信頼されたルート証明機関 (CA) 」と、「信頼された発行元」の両方に証明書が入っている必要がある。本番運用では、VeriSign などの第三者機関により発行された証明書を「信頼された発行元」に登録すればいいだけになる。

ちなみに、証明書は ActiveDirectory のグループセキュリティ機能を使えば、すべてのクライアントに配布することも可能なそうなので、意外と簡単にイントラネットでは利用できそうです。