2010年9月9日木曜日

Process.WaitForExit()は本当の意味で無期限待機しない

MSDNを見ると、Process.WaitForExitメソッドの引数無しバージョンの説明は次のようになっています。 
関連付けられたプロセスが終了するまで無期限に待機するように Process コンポーネントに指示します。
しかし、実際の動作はProcess.WaitForExit(Timeout.Infinite)と同じですので注意しましょう。
要するに、0x7FFFFFFFミリ秒後(25日後くらい)に、プロセスが終了していなくてもリターンします。(詳細はこちらを参照)

確かに、プログラム的には無期限ともいえますが、説明が紛らわしいですね。
戻り値がvoidなのもいやらしい。

サーバーでプロセスの異常終了を監視してメール通知するプログラムを作ったのですが、
再起動メールが来て焦ってログ確認したら問題無し。原因はこれでした。

2010年3月10日水曜日

Windows7でWebDAVサーバーを構築する方法

Windows7に搭載されているIIS7.5で、テスト用のWebDAVサーバーを構築しながら手順をまとめてみました。

構築するのは、基本認証に対応した書き込み可能なテスト用WebDAVサーバーです。ここでは手順は紹介しませんが、公開する場合はSSLも検討した方が良いでしょう。(基本認証はパスワードが平文で流れるため)
  1. WebDAV機能のインストール
  2. まずは、IISにWebDAVと基本認証機能をいれます。下図のように、「WebDAV発行」と「基本認証」を選択して追加します。(IISをデフォルトでインストールした状態では入っていません)
    注) Windows Vista / Windows Server 2008に搭載されているIIS7.0で行う場合、標準機能には含まれていませんので、ここからWebDAV拡張を入れることで対応できます。

  3. WebDAVユーザーを作成する
  4. WebDAVサーバーにアクセスするときに使うユーザーを作成しておきます。コントロールパネルのユーザーアカウントから、パスワードを設定した標準ユーザーを作成してください。ここではwebdavというユーザーを作りました。

  5. WebDAVを有効にする
  6. インストール直後、WebDAV機能は無効になっています。コントロールパネルの管理ツールの中からIISマネージャを起動します。左側のツリーを展開して"Default Web Site"を選択すると、右側に「WebDAVオーサリング規則」というアイコンがあると思いますので、ダブルクリックして開きます。
    右側に、「WebDAVの有効化」というボタンがあると思いますので押します。

  7. WebDAVルートの作成
  8. 次に"Default Web Site"の右クリックメニューから「仮想ディレクトリの追加」を選択します。
    今回は、"WebDAV"という名前で作成してみます。
    ちなみに、物理パスにはネットワークフォルダを指定することも出来ます。

  9. NTFSのアクセス権を設定する
  10. 標準ユーザー(Usersグループのメンバー)は読み取りアクセス権しか持っていませんので、追加したwebdavというユーザーが書き込みアクセスできるようにします。左側のツリーで、先ほど作成したWebDAVという仮想ディレクトリを選択し、右クリックメニューから「アクセス許可の編集」を選びます。
    「セキュリティ」タブを選択して、「編集」ボタンを押します。
    「追加」ボタンから、webdavユーザーを追加し、フルコントロールをチェックします。

  11. WebDAVのアクセス権を設定する
  12. 最後にWebDAVのアクセス権の設定を行います。新しく作った仮想ディレクトリ"WebDAV"を選択して、「WebDAVオーサリング規則」をダブルクリックします。そして、右上の「オーサリング規則の追加」ボタンを押します。
    「指定されたユーザー」を選択し、2.で作ったユーザー名webdavを入力します。アクセス許可には、「読み込み」と「書き込み」にチェックを入れます。
    これで設定完了です!

  13. アクセスしてみる
  14. うまく設定できたかを確認するには、WebDAVクライアントソフトを使うのが便利です。たとえばCarotDAVなどをつかって接続確認してみましょう。

IIS7.0で管理コンソールが大幅に変わったり、WebDAV拡張モジュールが標準で入っていなかったりとIISを敬遠していた方もいるかと思いますが、この機会に試してみてはどうでしょうか。

2010年2月17日水曜日

単一msiで多言語に対応したインストーラを作成してみる

InstallShieldとかを使わないと、インストーラの多言語対応は出来ないと思い込んでいた。というか世間的にそう思われてる?ちょっと検索しただけだと、無理というものが目に付く。Visual Studioで言語ごとにしかインストーラ作れないのがなあ。(これも思い込みかもしれないが)

少し本気で探してみると、下記のサイトが見つかった。アンドキュメントな方法ながらできるらしい。実際にこのとおりやってみたら、日、英、独に対応したmsiができたので、簡単にまとめてみる。
Multi-Language MSI Packages without Setup.exe Launcher

・Windows Installerの仕組み的にはどうなっているのか
ベースとなるmsiがあり、言語トランスフォーム(*.mst)を実行時にプロパティとして指定することで動作を変更できる仕組みがあるらしい。具体的には、下記のように指定できる。

msiexec.exe /i setup.msi TRANSFORMS=1041.mst

英語のsetup.msiに、日本語のトランスフォーム(1041.mst)を適用して表示言語を日本語に変えることが出来る。但し、mstファイルはmsiをベースに作成しておく必要がある。(各種ツールを利用)
InstallShieldなどのツールで多言語対応のSetup.exeを作成できるが、裏ではこんな動きをしているんだなと、初めて知った。

・実際に試してみる
前述のサイトの紹介されている方法は、実行時に指定するmstファイルをmsiに組み込んでしまうというもののようだ。地域と言語の設定が、mstファイルを組み込んだ言語になっている場合、自動でその言語で表示できるようになる。
  1. まず、mstファイルの組み込みに必要なスクリプトファイルを入手するため、Windows Installer SDKをインストールする。(これはPlatform SDKの一部として含まれている)
  2. 次に、デフォルト言語を英語にしてビルドしたmsiと、日本語とドイツ語のmstを作成する。動作検証をするのが主目的なので、手っ取り早くInstallShieldにて作成。
  3. [Windows Installer SDKのインストールフォルダ]\Samples\SysMgmt\Msi\Scripts内にある、WiSubStg.vbs及びWiLangId.vbsを、msiと同じフォルダにコピー。
  4. ここでスクリプトを実行。
  5. WiSubStg.vbs setup.msi 1041.mst 1041
    WiSubStg.vbs setup.msi 1031.mst 1031
    WiLangId.vbs setup.msi Package 1033,1041,1031
これで完了。地域と言語の設定をドイツ語にしてsetup.msiを起動すると、ちゃんとドイツ語で表示された。アンドキュメントな方法なので、心配な点はあるが、1つのmsiで多言語UIをサポートするインストーラが作成できることは確認できた。

2010年1月31日日曜日

Windows Azureの日本語の料金表まとめ

いよいよ明日から課金開始ですね。
ちょっと前までは、料金表が英語だったような気がするのですが、先ほどこちらを確認したら日本語がありました。

現在提供されているのは4つのプラン。
料金も日本円表示になっているので、ドルよりイメージしやすいかもしれません。
  • Windows Azure Platform 導入特別プラン (料金表)
  • Windows Azure Platform 標準プラン (料金表)
  • Windows Azure Platform 拡張プラン (料金表)
  • Windows Azure Platform 従量課金プラン (料金表)
あと、前回のエントリーで書いた疑問点はこちらを見て無事解決しました。

(1)デプロイしているとsuspend状態であってもCPU課金が発生
    やはり、これはデプロイした時点で仮想マシンが確保される為でしょうね。
    特別プランの25hでテストしようと考えている場合は、テスト後に必ずdeleteしないと直ぐに無料分が尽きます・・・。

(2)Production環境とStaging環境に課金で差は無い
    ProductionとStagingの両方で動かすと、CPUはx2必要になるみたいです。
    これもURL以外に機能的な差はありませんので、当然といえば当然ですね。

2010/2/19追記
CPU課金は1ヶ月の合計デプロイ時間で決まるわけではない模様。1時間のうち1分でもデプロイしていると1時間分課金が発生するということらしい。これは、なんか納得いかないなー。

2010年1月7日木曜日

Windows AzureのCPUの課金で心配な部分

2月から課金が開始されるWindows Azureだけど、本番環境に登録しようか迷い中。

Introductory Specialというプランがあって、6/31まではいくらか無料分があるらしい。
  • 25 hours of a small compute instance
  • 500 MB of storage
  • 10,000 storage transactions
1月末でCTP環境が使えなくなるし、いろいろと試すために本番環境に登録したいのだが、個人でやるとなると心配な部分が多い。ストレージは十分そうだけど、CPUが足りるかどうか。

で、ぶっちゃけCPU時間が25Hで足りるかというと、ここを見ると以下のような記述がある。

  • Compute time, measured in service hours: Windows Azure compute hours are charged only for when your application is deployed. When developing and testing your application, developers will want to remove the compute instances that are not being used to minimize compute hour billing. Partial compute hours are billed as full hours.

  • つまり、デプロイされていると、Stop状態であっても課金される認識でOK?
    deleteするの忘れて寝てしまうと、25Hなんてすぐ終わっちゃいますね・・・。
    Worker Roleも使った日には半日分です。(small instance * 2になるので)

    あと、Staging環境の扱いってどうなるんですかね。探したけど、どこにも見当たらず。
    なんとなくProduction環境と同じ扱いの気がしますが。StagingとProduction両方にデプロイしていると2つ分としてカウントされるんでしょうかねー?気になるところです。

    ちょっと怖いので、しばらく開発環境で我慢しようかな。
    まあ、MSDN Premium Subscriptionを確保できれば問題ないんだけどね・・・。

    2010年1月6日水曜日

    Web Service ClientがC:\Windows\Tempに書き込みできない例外

    Web参照を含むWebサービスクライアントを、Visual Studioでビルドしたときにできる [DllName].serializers.dll をデプロイに含める。
    そうしないと、実行時にC:\Windows\Tempに動的にファイルを作成しようとして、書き込みアクセス権がないユーザの場合に例外発生。

    詳細は↓参照。ジャストミートな内容。
    http://blogs.msdn.com/andreal/archive/2009/04/18/could-not-find-file-c-windows-temp-dll.aspx