DotNetNuke のモジュールのいくつかは、RSS フィードを使った配信が可能になっています。
しかし、HTML ヘッダに <link rel="alternate" ... /> を使った URL の記述が行われないため、RSS リーダーなどでフィードが自動認識されません。

以下の図は、IE7 にて DotNetNuke の Blog モジュールのページを表示した状態です。
XML アイコンが表示され、RSS フィードは配信されていますが、IE7 では認識されていません。

これを改善するには、DotNetNuke のページ設定で、ページヘッダータグの記述を追加します。

1. DotNetNuke に管理者でログオンして、ヘッダを追加するページの「ページ設定」を開きます。
   
   
   
   
2. 「ページ設定」で「高度な設定」を開きます。
   
   
   
   
3. 「ページ ヘッダー タグ」に下記の記述を追加して、ページ設定を更新します。
   
   <link rel="alternate" type="application/rss+xml" title="（タイトル）" href="（RSSフィードURL）" />
   
   
   
   
4. RSSフィードが自動認識されます。
   
   

これで、RSS リーダーなどのブックマークレットなどでも認識され、簡単に購読設定が可能となります。

なお、一つのページで複数の RSS フィードを配信している場合でも、上記のタグをそれぞれの RSS フィード URL を使って複数記述すれば配信可能です。

WPF/E ( Windows Presentation Foundation Everywhere ) の名称が Silverlight に変わり正式発表されました。

Microsoft Silverlight
http://www.microsoft.com/silverlight/default_01.aspx

名前、かっこいいです。
（というか、WPF/E ってコードネームだったんですね。知らなかった・・・orz）

あとは、どの程度普及していくかですが、個人的には、けっこう楽しみでもあります。

※上記サイトから、早速壁紙もダウンロードしました♪

ASP.NET 2.0 AJAX の応用として CodePlex にてリリースされている AJAX Control Toolkit には、多くの有用なコントロールが含まれています。

AJAX Control Toolkit
http://www.codeplex.com/AtlasControlToolkit

ただ、PopupControl 関連のコントロールには、現在のバージョン(2007-03-01 Release)では Internet Explorer のページ倍率を 100% 以外にすると、ポップアップウィンドウの表示位置がずれてしまい正しく表示されない不具合があるようです。

例えば、下記のページ
http://ajax.asp.net/ajaxtoolkit/Calendar/Calendar.aspx
の Calendar コントロール (CalendarExtender) のデモで試してみると、IE の表示倍率が 100% の場合はカレンダーが正しい位置にポップアップされます。

Fig : CalendarExtender (IE 100% View)

しかし、例えば 125% 表示で試すと、カレンダーの表示位置が正しい位置より、より大きくオフセットされて表示されてしまいます。

Fig : CalendarExtender (IE 125% View)

DropDown コントロール (DropDownExtender)
http://ajax.asp.net/ajaxtoolkit/DropDown/DropDown.aspx
でも、以下のようになってしまいます。

Fig : DropDownExtender (IE 100% View)

Fig : DropDownExtender (IE 125% View)

正式に Fix されるまで、使用には注意が必要です。

Microsoft Expression シリーズが MSDN Premium 以上で提供されるようです。

ネタ元：Expression web design applications now available on MSDN
http://blogs.technet.com/seanearp/archive/2007/04/03/expression-web-design-
applications-now-available-on-msdn.aspx

私は Visual Studio Team Edition for Software Developers を契約しているので、とりあえず Expression Web と Blend は入手出来る模様（個人的には Design も欲しかった～）。

これで、WPF ( XAML ) がますます楽しめそうです。よかったよかった。

ASP.NET AJAX をいろいろと調べていまして、そのメモを兼ねて一つ記事をアップします。

[The Official Microsoft ASP.NET 2.0 Site] にあるサンプル
「How Do I: ASP.NET AJAX Enable an Existing Web Service?」
http://www.asp.net/learn/videos/view.aspx?tabid=63&id=82

などでは、

function Button1_onclick() {
ret = SimpleService.SayHello(document.getElementById('Text1').value,
                             OnComplete, OnTimeOut, OnError);
return(true);
}

などと、Web メソッドの非同期呼び出しを記述しています。

幸いなこと（？）に JavaScript ではエラーとならずに実行されるのですが、正確にはこの記述は間違いです（以前の Atlas 時代の形式です）ので注意してください。

正確には、プロキシを使った Web サービスの呼び出しのプロトタイプは

myServiceProxy.MyServiceMethod(param1, ... , paramN,
               SucceededCallback, FailedCallback, userContext)

となっています。

参考：Generated Proxy Classes Web Service Methods
http://ajax.asp.net/docs/ClientReference/Sys.Net/GeneratedProxyClasses/
WebServiceMethods.aspx

サンプルのままだと、コールバック関数の OnComplete は問題ないのですが、タイムアウトでの処理のつもりで書いたコールバック関数 OnTimeOut がエラー発生時にも呼び出されてしまいます。

最新の ASP.NET AJAX では、タイムアウトとエラー発生時のコールバックは統一されており、同じ関数が呼び出されるようになっています（プロトタイプでは FailedCallback 引数に指定した関数）。

私は、このサンプルのデモムービーを見ていて、ちょっと混乱しました・・・

さて、参考までに・・・

ASP.NET AJAX を使って、クライアントサイドのスクリプトから Web サービスを呼び出すには、Web サービスのメソッドに System.Web.Script.Services 名前空間の ScriptService 属性 (ScriptServiceAttribute)が必要となります。

[ SimpleService.cs ]

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Web.Script.Services;

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ScriptService]
public class SimpleService : System.Web.Services.WebService
{
  [WebMethod]
  public string SayHello(string name)
  {
    return "Hello : " + name;
  }
}

そして、aspx ソースに asp:ScriptManager を追加して、その子要素に Services/asp:ServiceReference を下記のように追加すると、Web サービスの呼び出しに必要な JavaScript プロキシコードが生成されます。

[ Default.aspx ]

<asp:ScriptManager runat="server" ID="scriptManager">
  <Services>
    <asp:ServiceReference Path="SimpleService.asmx" />
  </Services>
  <Scripts>
    <asp:ScriptReference Path="UsingSimpleService.js" />
  </Scripts>
</asp:ScriptManager>

生成されたプロキシスクリプトを使うと、クライアントサイドのスクリプトで Web サービスの非同期の呼び出しが、下記のコードのように簡単に行えるようになります。

[ UsingSimpleService.js ]

function pageLoad()
{
  SimpleService.set_timeout(3000);
  SimpleService.set_defaultUserContext("Default context");
  SimpleService.set_defaultSucceededCallback(SucceededCallback);
  SimpleService.set_defaultFailedCallback(FailedCallback);
}

function Button1_onclick()
{
  SimpleService.SayHello(document.getElementById("Text1").value);
}

function Button2_onclick()
{
  SimpleService.SayHello(document.getElementById("Text1").value,
                         SucceededCallback,
                         FailedCallback,
                         "User context");
}

function SucceededCallback(result, userContext, methodName)
{
  var text = result + " (" + userContext + ")" + " [" + methodName + "]";

  document.getElementById("Label1").innerText = text;
}

function FailedCallback(error, userContext, methodName)
{
  var text = "Service Error : " +  error.get_message() +
             " (" + userContext + ")" + " [" + methodName + "]";

  document.getElementById("Label1").innerText = text;
}

このプロキシを使った Web サービスの呼び出しでは、pageLoad で行っているように、プロキシの set_defaultXXXX メソッドで、コールバック関数を指定して Button1_onclick で Web サービスメソッドの呼び出しのみを行う方法と、Button2_onclick で行っているように Web サービスの呼び出し時にコールバック関数を指定することもできます。

ここで、プロキシを使った Web サービスの呼び出しのプロトタイプは前述のように

myServiceProxy.MyServiceMethod(param1, ... , paramN,
               SucceededCallback, FailedCallback, userContext);

となります。

また、各コールバック関数のプロトタイプは下記の通りとなります。

function SucceededCallback(result, userContext, methodName);
function FailedCallback(error, userContext, methodName);

ASP.NET AJAX は、UpdatePanel を使えばとても簡単に Web アプリケーションの AJAX 化ができるのですが、本格的な ASP.NET AJAX アプリケーションを作り始めると、やはりいろいろと奥が深いところがあり楽しいですね。

【参考】
Generated Proxy Classes
http://ajax.asp.net/docs/ClientReference/Sys.Net/GeneratedProxyClasses/default.aspx

ユーザーアカウント制御 (User Account Control) 機能による昇格時の確認ダイアログは、セキュリティで保護されたデスクトップ（背景が暗くなった状態で UAC の昇格確認ダイアログだけがアクティブになったデスクトップ）で表示されるため、簡単にスクリーンショットを取ることができません。

私は、今まで UAC の昇格確認ダイアログのスクリーンショットだけは、Virtual PC 2007 上で起動した Windows Vista を使って作成していました。

でも、こんな方法もあるんだな、ということでご紹介。

1. コントロールパネルの「システムとメンテナンス」－「管理ツール」で「ローカル セキュリティ ポリシー」を開きます。
2. ウィンドウ左側のツリーで、「セキュリティの設定」－「ローカル ポリシー」－「セキュリティ オプション」を開き、右側の「ポリシー」リストで「ユーザーアカウント制御:昇格のプロンプト時にセキュリティで保護されたデスクトップに切り替える」を探し、ダブルクリックします。
3. 「ローカル セキュリティの設定」タブで、デフォルトでは「有効」になっていますが、これを「無効」に変更します。

この設定であれば、Snipping Tool などで簡単に UAC 制御のダイアログのスクリーンショットを取ることができます。

但し、セキュリティで保護されたデスクトップでは Aero が無効になっているため、UAC の昇格確認ダイアログも半透明ではないウィンドウ表示なのですが、セキュリティで保護されたデスクトップを使用しない場合の UAC の昇格確認ダイアログは、Aero が有効になっていると半透明のウィンドウ表示となってしまいます。

※ネタ元
http://japan.zdnet.com/sp/feature/shinder/story/0,2000087897,20342824-6,00.htm

ユーザーアカウント制御 (User Account Control) 機能は、Windows Vista のセキュリティ機能の中で最も重要なものですが、管理者としてログオンしていても許可を求めるダイアログが表示され、面倒に思うこともあるでしょう。

ユーザーアカウント制御 (UAC) は、コントロールパネルの「ユーザーアカウント」－「ユーザーアカウント制御の有効化または無効化」で無効にすることもできますが、Vista のセキュリティ設定上あまりおすすめできません。

そこで、ユーザーアカウント制御機能は有効にしたまま、管理者としてログオンしている場合にのみ、以下の方法で昇格確認ダイアログを表示させないようにすることができます（自動的に昇格する）。

1. コントロールパネルの「システムとメンテナンス」－「管理ツール」で「ローカル セキュリティ ポリシー」を開きます。
2. ウィンドウ左側のツリーで、「セキュリティの設定」－「ローカル ポリシー」－「セキュリティ オプション」を開き、右側の「ポリシー」リストで「ユーザーアカウント制御:管理者承認モードでの管理者に対する昇格時のプロンプト動作」を探し、ダブルクリックします。
3. 「ローカル セキュリティの設定」タブのドロップダウンリストではデフォルトで「同意を要求する」が選択されていますが、これを「確認を要求しないで昇格する」に変更します。

これで、管理者ユーザーでは、UAC の昇格確認ダイアログが表示されなくなります。
※標準ユーザーでは、これまでどおり UAC の昇格ダイアログが表示され、管理者パスワードを入力しないと昇格できません。

管理者として常にログオンしているのであれば、覚えておいて損はないと思います。

前回の記事「UAC (User Account Control)と C/C++ MFC アプリケーション（その１）」の続きです。

前回は、Application Manifests と Virtualization について解説しました。今回は、それらの組み合わせによるアプリケーションの挙動についてサンプルアプリケーションを元に解説します。

● マニフェストなし、または requestedExecutionLevel 要素記述なしの場合

この場合は、Virtualization 機能により、権限のないフォルダやレジストリキーへの書き込みがリダイレクトされ、エラー無く実行されます。ただし、この場合に注意が必要なのは、インストール時に設定情報などのファイルを %PorgramFiles% のインストールフォルダにインストールし、そのファイルをアプリケーション実行時に読み書き可能なモードで開いたりした場合に、%USERPROFILE%\AppData\Local\VirtualStore\Program Files\ 以下のフォルダにリダイレクトされるので、設定情報が読み込めないなどの不具合が発生する可能性があります。

図：サンプルアプリケーションの実行（マニフェスト無しの場合）

C:\Program Files\BitWiz\test.txt の作成に成功している（上図）が、C:\Program Files\BitWiz には test.txt が生成されていない（下図）。

図：サンプルアプリケーションの実行フォルダ

Virtualization（仮想化）機能により、C:\Users\\AppData\Local\VirtualStore\Program Files\BitWiz フォルダに test.txt が生成されている（下図）。

図：C:\Users\\AppData\Local\VirtualStore\Program Files\BitWiz フォルダ

サンプルアプリケーションの実行結果では、HKEY_LOCAL_MACHINE\SOFTWARE\BitWiz のレジストリキーのオープン(KEY_ALL_ACCESS)に成功しているが、実際は HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\BitWiz キーがオープンされて値が取得されている。

図：レジストリキーのリダイレクト

● マニフェストありで、requestedExecutionLevel 要素記述ありの場合

Virtualization 機能は無効となり、仮想化（ファイルやレジストリのリダイレクション）は行われません。

■ asInvoker
requestedExecutionLevel 要素の level 属性値を asInvoker とした場合、親プロセスと同じ特権で実行されるため、書き込み権限のない C:\Program Files や HKEY_LOCAL_MACHINE への書き込みなどはエラーとなります。

図：サンプルアプリケーションの実行（マニフェストあり(asInvoker)の場合）

asInvoker 属性値により権限の昇格なしで実行されているため、ファイルの作成、レジストリキーのアクセスともに失敗している。Virtualization 機能も無効となり、リダイレクトも行われない。

■ highestAvailable / requireAdministrator
requestedExecutionLevel 要素の level 属性値に highestAvailable や requireAdministrator とすると、実行時に UAC 昇格確認ダイアログが表示される。
ここで、実行を許可すると C:\Program Files や HKEY_LOCAL_MACHINE への書き込みなどが可能となる。

図：実行時の UAC ダイアログ

実行時に必ず UAC 昇格確認ダイアログが表示される（上図）。

図：サンプルアプリケーションの実行（マニフェストあり(requireAdministrator)の場合）

ファイルの作成、レジストリキーのアクセス共に成功している（上図）。

図：サンプルアプリケーションの実行フォルダ

C:\Program Files\BitWiz\test.txt が生成されている。
また、マニフェストの requireAdministrator 属性値により、自動でアプリケーションアイコンにシールドアイコンが表示され、権限の昇格を行わないと実行できないことがわかる（上図）。

図：HKEY_LOCAL_MACHINE レジストリキーへのアクセス

指定どおり、HKEY_LOCAL_MACHINE\SOFTWARE\BitWiz レジストリキーのオープン(KEY_ALL_ACCESS)に成功している（上図）。

● インストーラ検出技術の条件に一致した場合

基本的には requestedExecutionLevel 要素の level 属性値が優先されますが、この要素記述が無い場合は "install" "setup" "update" などのキーワードがファイル名やバージョンリソースに含まれるとインストーラと判断され、UAC 昇格確認ダイアログが表示されることとなります。

図：ファイル名に "Setup" という文字列を含んだアプリケーション

マニフェストに requestedExecutionLevel 要素の記述を行っていないが、アプリケーションアイコンにシールドアイコンが表示されている（上図）。

図：インストーラとして検出されたアプリケーションの終了後に表示される確認ダイアログ

アプリケーション実行終了後、正しくインストールされたかの確認ダイアログが表示される（上図）。

さて、アプリケーションがインストーラとして検出される条件はどのようになっているのでしょうか？

以下は
「Installer Detection Technology」
http://technet.microsoft.com/en-us/windowsvista/aa905117.aspx
からの抜粋です。

Installer Detection only applies to:

1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with LUA enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

- Filename includes keywords like "install," "setup," "update," etc.
- Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
- Keywords in the side-by-side manifest embedded in the executable.
- Keywords in specific StringTable entries linked in the executable.
- Key attributes in the RC data linked in the executable.
- Targeted sequences of bytes within the executable.

ファイル名だけでなはく、バージョンリソースなどに含まれるキーワードでも判断されるようです。

● UAC 対応のシナリオ

■ 意図的に仮想化（Virtualization）させる場合

アプリケーションマニフェストに requestedExecutionLevel 要素の記述を行わない。
※注意点
インストール時等に C:\Program Files にコピーされたファイルなどへの読み書きを前提にしている場合、そのファイルをWriteで開く時点で C:\Users\\AppData\Local\VirtualStore\Program Files\ にリダイレクトされるので、ファイルが存在しないなどのエラーとなる。

■ 仮想化（Virtualization）を行わずに、且つファイルやレジストリへのアクセス権限も正しく行っていて、管理者権限での実行が不要な場合。もしくは実行ファイル名に "install", "setup", "update" などの文字を含める必要があるが、インストーラとして認識されたくない場合

アプリケーションマニフェストに requestedExecutionLevel 要素の記述を行い level 属性値を asInvoker とする。

■ 仮想化（Virtualization）は行いたくないが、Program Files や HKEY_LOCAL_MACHINE などへの書き込み参照が必要な場合

アプリケーションマニフェストに requestedExecutionLevel 要素の記述を行い level 属性値を requireAdministrator とする。

■ 仮想化（Virtualization）を行い、かつファイル名などに "install", "setup", "update" などの文字を含める必要がある場合

不可能。必ずインストーラとして認識されてしまい管理者権限に昇格しないと実行できないため、この場合は仮想化を行うことはできない。

● おわりに

Windows Vista 対応のアプリケーションを開発する場合、UAC への理解が必須と思われますが、慣れないうちはなかなかわかりにくいところです。
今回は、マニフェストをアプリケーションリソースに埋め込む方法でいろいろと試してみましたが、マニフェストを外部ファイルとして実行ファイルと同じフォルダに置いた場合、若干異なる動きをすることを確認しています。時間がとれればそのあたりも調べてみたいと思っていますが、とりあえずは、埋め込みマニフェストを使い、アプリケーションの権限昇格の要/不要を制御するか、Virtualization 機能を前提としたアプリケーション実装を行うことが確実でしょう。
また、Authenticode 証明書などでアプリケーションに署名を行うと、UAC の昇格確認ダイアログの表示が変わったりするのですが、今回は署名されている場合の説明は割愛します。

Windows Vista の UAC (User Account Control) と、C/C++ MFC アプリケーションなどのアンマネージ（ネイティブ）アプリケーションについてまとめてみます。

既存の C/C++ & MFC アプリケーションを Windows Vista に対応させるのに、最も注意しなくてはならないのが、UAC (User Account Control) への対応でしょう。

アプリケーションマニフェストの有無やマニフェストの記述内容によって、UAC 管理下でのアプリケーションの動作がそれぞれ異なります。

● Application Manifests

アプリケーションマニフェストとは、アプリケーションが実行時にバインドする共有 side-by-side アセンブリ（WinSxS フォルダにインストールされる mfc80.dll, comctl32.dll 等のネイティブライブラリ）のバージョンを指定したりするための XML ファイルです。

代表的なところでは、Windows XP でビジュアルスタイルを有効にするために comctl32.dll のバージョンを指定するのに多く使用されています。

このアプリケーションマニフェストは、実行ファイルの名前＋.exe.manifest (AppName.exe.manifest) として外部 XML ファイルとすることも、アプリケーションにリソースとして埋め込むこともできます。

Visual Studio 2005 で MFC アプリケーションのプロジェクトを作成すると、stdafx.h に以下の記述が生成されて、comctl32.dll のバージョン6を使用するためのアプリケーションマニフェストがデフォルトでアプリケーションリソースとして埋め込まれるようになります。

#ifdef _UNICODE
#if defined _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_IA64
    ........
#elif defined _M_X64
    ........
#else
    ........
#endif
#endif

外部 XML ファイルとしてマニフェストを用意する方法は簡単ですが、上記のようにアプリケーションリソースとしてマニフェストが埋め込まれている場合、外部マニフェストファイルを使用すると、リソースに埋め込まれたマニフェストが無効になってしまいますので注意が必要です。

MFC アプリケーションを Windows Vista の UAC へ対応させるにあたり、アプリケーションマニフェストが重要な要素となりますが、上記のようなことから、マニフェストはアプリケーションリソースに埋め込む方法を推奨します。ここでも埋め込みマニフェストを使って UAC 対応について解説していきます。

まず、UAC 対応に必要なアプリケーションマニフェストの記述例を下記に示します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="AppName"
     type="win32"/>

  <description>Description of your application</description>

  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>

</assembly>

ここで重要なのが requestedExecutionLevel 要素の level 属性値です。

requestedExecutionLevel のスキーマは下記のとおりです。

<requestedExecutionLevel
   level="asInvoker|highestAvailable|requireAdministrator"
   uiAccess="true|false"/>

level 属性の値には以下のいずれかを記述します。

asInvoker
－ アプリケーションは親プロセスと同じトークン（権限）で実行します

highestAvailable
－ アプリケーションは現在のユーザが取得できる最も高い特権で実行します

requireAdministrator
－ アプリケーションは管理者として実行され、管理者の完全なトークンで実行されることを要求します

通常、管理者権限への昇格が不要なアプリケーションの場合は asInvoker を使い、管理者権限で実行すべきアプリケーションの場合は requireAdministrator を使うことになるでしょう。

Visual Studio 2005 C++ プロジェクトでマニフェストファイルをリソースに埋め込むには、プロジェクトのプロパティの【構成プロパティ】－【マニフェスト ツール】-【入力と出力】で、「追加のマニフェスト ファイル」に上記のマニフェストを記述したファイルを指定するのが簡単です。ここで「埋め込みマニフェスト」が「はい」となっていることも確認してください。

図：VS 2005 プロパティページ

● Virtualization

では次に、UAC 対応にあたり Windows Vista のもう一つ重要な機能を解説します。
Windows Vista では、Virtualization（仮想化）という技術により、権限のないフォルダやレジストリキーに書き込みを行った場合に単にエラーとしてしまうのではなく、各ユーザ毎に用意された書き込み可能な特別なフォルダやレジストリキーにリダイレクトして、あたかも何事もなかったかのようにアプリケーションを実行させることができます。

■ ファイルの仮想化（File Virtualization）

%PorgramFiles% などのフォルダへ、書き込み権限を持たないアプリケーションがファイルを生成しようとした場合などに、自動的に %USERPROFILE%\AppData\Local\VirtualStore\Program Files\ へリダイレクトされ、エラーとならずに実行することができます。

【例】
C:\Program Files\Hoge
へファイルを生成しようとすると、実際には

C:\Users\\AppData\Local\VirtualStore\Program Files\Hoge
へファイルが生成される。

■ レジストリの仮想化（Registry Virtualization）

HKEY_LOCAL_MACHINE などのレジストリキーに、書き込み権限を持たないアプリケーションがキーや値を生成使用とした場合、自動的に HKEY_CURRENT_USER\Software\Classes\VirtualStore へリダイレクトされ、エラーとならずに実行することができます。

【例】
HKEY_LOCAL_MACHINE\Software\Hoge
へキーを生成しようとすると、実際には

HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Hoge
へキーが生成される。

◇◇◇

さて、UAC 管理下におけるアプリケーションの挙動は、アプリケーションマニフェストの requestedExecutionLevel 要素の有無や level 属性値の記述により、いろいろと変わってきます。次回は、それらの組み合わせによるアプリケーションの挙動について解説します。

※ブログ記事としては、ちょっと長くなってしまったので、２回に別けます。

前回の記事 Visual Studio 2005 SP1 と Windows Vista で書きました Visual Studio 2005 SP1 Update for Windows Vista が正式にリリースとなりました。

Visual Studio 2005 Service Pack 1 Update for Windows Vista

Windows Vista で Visual Studio 2005 を使用する場合はこちらをインストールしましょう。

最近、Windows Vista に Visual Studio 2005 SP1 をインストールしました。
Vista で Visual Studio 2005 を使うには SP1 が必要で、さらに管理者権限で実行する必要があります。

ということで、管理者権限で実行したところ、

『Visual Studio 2005 SP1 を使用するには、Windows Vista 用の更新プログラムが必要です。』

とのダイアログが表示されて、ちょっとビックリしてしまいました。
「Windows Vista 用の更新プログラム」というものが何を指しているのか知らなかったもので・・・

調べてみると、

Visual Studio 2005 Service Pack 1 Update for Windows Vista (Beta)

なるものが「Windows Vista 用の更新プログラム」に相当することがわかりました。
残念ながら現時点ではベータ版で、正式版は2007年の第1四半期を予定しているらしいです。

参考：よく寄せられる質問 : Visual Studio と Windows Vista

とりあえずはこの「Windows Vista 用の更新プログラム」ベータ版をインストールしなくても使用できるようですので、ベータ版をインストールしたくない方はもう少し我慢しましょう。

私は、近々ベータ版をインストールしてしまう予定です。
その後、

Visual Studio 2005 extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP

をインストールして、WPF & WCF を楽しもうかと策略中...

Windows Vista ではネットワークマップを表示することができ、各コンピュータのIPアドレスなどもポップアップで表示出来るので、結構便利です。
但し、このマップに適切に配置されるにはコンピュータが Link-Layer Topology Discovery (LLTD) と呼ばれる検出プロトコルに対応している必要があり、現状では Windows 系 OS では Vista しか標準で対応していません。

図では、AIVMWXP という Windows XP マシンと BITWIZ01 という Windows Server 2003 マシンがネットワークマップに配置されていません。

しかし、あきらめるのはまだ早く、Windows XP 向けに LLTD レスポンダの追加コンポーネントがリリースされていますので、これをインストールすると Windows XP ベースのコンピュータもマップに配置されるようになります。

• Link Layer Topology Discovery (LLTD) レスポンダ (KB922120)
• Windows Vista のネットワーク マップに Windows XP を実行しているコンピュータが表示されない

AIVMWXP という Windows XP マシンに、この LLTD レスポンダをインストールすると、次の図のようにネットワークマップに無事に配置されるようになります。

さてさて、Windows 2000 や Windows Serve 2003 向けの LLTD レスポンダコンポーネントも早くリリースされませんかねー。

先日参加した Microsoft Application Platform Summit で知ったのですが、MSDN サブスクリプション契約をしていると、送料 $25 の負担だけで英語版の MSDN Magazine が１年間購読できるらしいです。

今では Web 上で MSDN マガジン日本語版を読むことができるようになりましたが、やはり紙媒体として欲しいなと思っていました。例えば電車の中とか PC やインターネットが使えないときにも読むことができるので、時間が有効に使えるんですよね。

MSJ の頃からずっと愛読していたので、MSDN マガジンが2003年4月号で休刊になり、とても残念に思っていました。本当は日本語版の紙媒体としての復活を希望していますが、とりあえず英語版の MSDN Magazine が格安で入手できるので良しかと。

ということで早速申し込んでみました。

・・・

が、申し込みでちょっと問題発生。

MSDN のベネフィットポータルへログインして、一番下に表示されている「MSDN Magazine Subscription」のリンクをクリックしても、申し込み画面が表示されずページが再描画されるだけで、何も出来ないんです。
なんだこれ？と思い、とりあえず MSDN 事務局に問い合わせをしてみました。

回答は、「IE7 の場合、なんのメッセージも表示されずにポップアップがブロックされてしまい、申し込み画面が表示されないことがあります。」とのこと。これは IE6 だと問題ないらしいのですが・・・

ということで、IE7 のメニューで
[ツール]－[ポップアップ ブロック]－[ポップアップ ブロックを無効にする]
を行った後に試したところ、申し込みのウィンドウが表示されるようになりました。

ということで、早く送られてこないかな～と期待しつつ、一方では本当に英語の雑誌を真面目に読むのか？？と一抹の不安を感じざるを得ない今日この頃なのでした・・・

このたび、「Google ガジェットプログラミング入門」という書籍を執筆させていただき、本日無事に発売となりました。ここで改めて関係者の皆さんにお礼を申し上げます。ありがとうございました。

昨年１０月から本格的に執筆作業に取りかかっていていたのですが、途中で Google デスクトップのバージョンアップと共に SDK も変更されたり、始めは Windows XP でスクリーンショットを作成していたのを Windows Vista で作成し直したりと、いろいろ環境の変化に追従しながらの作業となりました。それでも、本当に楽しく執筆作業ができたので、良い経験となりました。

詳しくは 書籍紹介 のページを見てくださーい。

この度「日本の天気予報」ガジェットの最新版(Ver.2.0.0.0)をリリースしました。
まだ Google デスクトップの「ガジェットの追加」の一覧には表示されませんが、こちらのページからダウンロードできますので、興味のある方はご利用ください。

「日本の天気予報」ガジェットの最初のバージョンを作成したときから、Google デスクトップ自体もバージョンアップを重ね、それにともない、ガジェットの作成方法も変わってきました。
初期の「日本の天気予報」ガジェットは、リリースしてまもなく旧式のガジェットになってしまいました。

初期のバージョンは、C++をベースに作成しWindows Installer(.msi)でインストーラを作成していましたが、現在では、ガジェットの処理をJavaScriptを使って記述し関連ファイルをZIP形式で圧縮したGoogleガジェットファイル形式(.gg)で作成することが推奨されています。

Googleからも「.msi 形式から .gg 形式にコンバートしてください」とのメールが来ていて、また、何人かのユーザの方からもメールでご要望等を受けていたのですが、時間の都合でなかなかバージョンアップに着手できませんでした。

そうこうしているうちに、Google デスクトップ 4.5 がリリースされてサイドバーの外観が変わり、ガジェットAPIも一部変更されたので、「日本の天気予報」ガジェットが正常に動作するか動作確認してみたところ、詳細ビューの表示が真っ黒になってしまったり、右上のアイコンが表示されなかったりと、いくつか不具合が出てきてしまいました（一応TODOリストには入っていたのですが・・・）。

こりゃ、いい加減バージョンアップしないとと思いまして、少しまとまった時間も取れたこともあって、何とか最新版をリリースすることが出来ました。

JavaScriptベースで書き換えたことにより、描画関係でC++で出来ていたことが一部出来なくなってしまったことがあり少し残念なのですが、それ以上に、最初のバージョンに無かった機能が追加出来た上、開発工数も削減できたので、JavaScript も侮れないなと感じました。

この Google デスクトップガジェットだけでなく、もうすぐ発売になる Windows Vista のサイドバーガジェットも JavaScript を使って手軽にプログラミングできます。

興味がある方は、ぜひ JavaScript を使ったガジェットプログラミングにチャレンジしてみてくださーい。

「日本の天気予報プラグイン for Google デスクトップ」が、Google デスクトップ ガジェットコンテストで Honorable Mention（佳作）に入賞してしまいました。

Results of the Google Desktop Gadget Contest!

いやぁ、ビックリしました。
日本人しか喜ばないようなガジェットなので、まさか選出されるとは思ってなかったのですが。

他の入賞作品みると、みんなカッコイイのばかり。
本当にこんなの選ばれちゃっていいの？って気持ちで、恐縮してます・・・

本当にありがとうございました。

先日公開しました「日本の天気予報プラグイン for Google デスクトップ」ですが、無事に Google の承認がおりて Google Desktop Gadget ダウンロードサイト に掲載されました。

Google Desktop Plug-ins - Weather forecasts of Japan

早速、Google Developer's T-shirt と Google ロゴの入ったキャップとボールペンが US から送られてきましたー。

このサイトに掲載されるまでに、Google 側でいろいろとテストをしていただけるのですが、そのときに「気温表示が "---" となる」ことについてご指摘を受けました。

結論から言えば、これは livedoor Weather Hacks お天気Webサービス から取得している天気データに時間帯によっては気温データが含まれていないためで仕様となるのですが、疑問に思われる方もいらっしゃると思いますので、下記に簡単に気温が非表示になる時間帯についてまとめておきます。

【天気データ更新時間 0:00 】
今日 最高気温あり／最低気温あり
明日 最高気温なし／最低気温なし
明後日 最高気温あり／最低気温あり

【天気データ更新時間 5:00 】
今日 最高気温あり／最低気温なし
明日 最高気温なし／最低気温なし
明後日 最高気温あり／最低気温あり

【天気データ更新時間 11:00 】
今日 最高気温あり／最低気温なし
明日 最高気温あり／最低気温あり
明後日 最高気温あり／最低気温あり

【天気データ更新時間 17:00 】
今日 最高気温なし／最低気温なし
明日 最高気温あり／最低気温あり
明後日 最高気温あり／最低気温あり

現在のところではこのような状態でしょうか（今後この状態が変わる可能性がありますが）。

まず、今日の天気データでは基本的に予報というより現時点での天気のデータが得られます。気温に関してはその日の最低気温・最高気温が記録された時点で天気データには記載されなくなるようです。つまり、日が変わった 0:00 - 5:00 の間では最高・最低気温ともデータ“あり”となりますが、朝方に最低気温が記録されると、その後の天気データ（朝 5:00 以降のデータ）では最低気温データが“なし”となるようです。そして、昼過ぎに最高気温が記録されるとその後の天気データ（17:00 以降のデータ）で最高気温データが“なし”となるようです。

次に明日の天気データですが、日が変わった 0:00 の時点では翌日の気温予報データが発表になっていないためか、最高・最低気温データ共に“なし”になります。その後、翌日の気温予報が発表になると、そのデータが取得できるようになるようです（11:00 以降）。

明後日の天気データは、今のところ常に表示されますので問題ないですね。

本当は、気温データに関しても常に表示出来ればいいのですが、無料で天気予報データを取得できるサイトは少ないので、今回利用させていただいている livedoor お天気Webサービス には大変感謝しております。

Office 2007 から標準のファイル形式が Open XML Formats になりますが、これは Microsoft 独自のフォーマットで、OpenOffice などの OpenDocument Format (ODF) とは同じ XML 形式ではありますが、互換性がありません。

そのため、これら互換性のない２つのフォーマットを相互変換するツールを開発するためのプロジェクトが開始され、早速 Word 2007 で OpenDocument ファイルを開くためのアドイン試作版が公開されたようです。

MS、「MS Office」の“OpenDocument”対応を表明、アドインの試作版を公開

このツールはBSD ライセンスのもと、オープンソースとして開発されるそうで、SourceForge.net からダウンロード可能となっています。

SourceForge.net: ODF Add-in for Word 2007

Open XML Formats <--> OpenDocument の相互変換って必要になるだろうなぁと思い、私の ToDo リストに入っていたのですが、別に私ごときがやる必要もなかったですね・・・

ちなみに Open XML Formats の詳細は下記にて公開されてます。

Introducing the Microsoft Office (2007) Open XML File Formats

そろそろ本格的に Windows Vista の評価を始めようと思っていまして、まずは評価用 PC の調達を検討中です。そんな中で 「Windows Aeroの謎に迫る」 の記事はとても参考になりました。

それにしても 256MB のグラフィックスメモリでも厳しいとは。まぁ、β版だから致し方ないにしても、さすがに 512MB のグラフィックスカードを用意するのは厳しいですね。

今回の記事は NVIDIA の GeForce を使用した評価でしたが、次回は ATI で試すらしいので、期待してます。

事務所のファイルサーバが稼働開始しました。といっても、今のところ常時稼働ではない単なるバックアップサーバですが。

数年前に現役を引退した PC を利用して、ハードウェア RAID（ミラーリング）とギガビットLAN 対応し、復活させました。

主なスペックは下記の通り。

• CPU : Pentium III 1B GHz
• Mother Board : ASUS CUSL2-C
• Memory : PC133 SDRAM(CL3) 512MB (256MB x 2)
• HDD : Seagate ST380021A(80G) x 2
• GPU : Millennium G450
• LAN : 玄人志向 GbE-PCI2
• RAID : 玄人志向 SAPARAID-PCI
• OS : Windows Server 2003 R2

ファイルサーバ用途なので十分なスペックで安定動作しています。欲を言えばメモリを 1G にしたかったのですが、今どき PC133 SDRAM は入手しづらく断念しました。暇があったら秋葉の中古パーツショップで探してみます。

それと、一応 PC はギガビット LAN に対応しましたが、ハブがまだ未対応なので、実力を発揮できていません（笑）。この辺は近日中にでも・・・

本当は、電源も静音タイプのものに入れ替えたかったのですが、予算の都合上諦めました。まぁ、常時稼働でないので良しかと。

オペレーションはメインマシンからリモートデスクトップで操作してます。結構快適です。