Win7 Pro(x86) で動いていた .xbap が Win8 Pro(x64) で動かない?

WPF ブラウザーアプリケーション

会社内のツールのいくつかは、WPF ブラウザーアプリケーションとして実装・運用している。

すなわち拡張子が .xbap のファイルにパッケージされて HTTP 経由で配信される、Internet Explorer の枠内で起動する .NET アプリケーションだ。

社内で運用しているローカルな認証局から発行した証明書で電子署名し、完全信頼モデルで動作させるようにビルドしてある。

WPF ブラウザーアプリケーションの利点

WPF ブラウザーアプリケーションは、とくに署名&完全信頼に設定している場合、つまるところは .NET の EXE ファイルとおおむね同等である。
単に見た目上は Internet Explorer の枠内だが実行の舞台はあくまでもクライアント PC 上である。

いっぽうで、社内のクライアントPCにインストールする手間もなく、となるとバージョンアップも取り立ててなにかする必要もない。
社内のポータル Web ページ上から、.xbap を配置してある URL へのリンクを掲載しておくだけで運用できるのが便利だ。

ClickOnce でも同様の仕掛けは可能である。
実際、WPF ブラウザーアプリケーションは、ClickOnce の変わった形態、として理解するのもよい。
あたかも Web ページであるかのように、よそのページから透過的に遷移して使えるところが違いだろうか。

Windows8 Pro x64 で動作しない?

とまぁ、こういう背景もあって運用してきた 社内 WPF ブラウザーアプリケーション。

しかし先日、Windows8 Pro 64bit 版の Internet Explorer 10 デスクトップ版からアクセスしてみたところ、なんと、正常動作しなかった。

現象としては、WPF ブラウザーアプリケーションを配置してある URL へのリンクをクリックすると、ダウンロードマネージャのウィンドウが開いて .xbap ファイルのダウンロードが始まり(そもそもこの挙動からして違う)、それをどうやら開こうとするっぽいのだが、するとまだ同じ .xbap のダウンロードがやり直され... と .xbap のダウンロードとオープンが超高速で繰り返される無限ループに陥るのだ。

.NET Framework のバージョンは大丈夫?

WindowsXP SP3 x86 および Windows7 SP1 x86 では、相変わらずちゃんと動作する。

この WPF ブラウザーアプリケーションの動作環境は、.NET Framework 3.5 SP1 がインストールされていれば十二分な環境で、問題となっている Win8 Pro x64 上にも、当然、ちゃんと .NET 3.5 SP1 を追加インストール済みだ (※Win8 には既定では .NET 4しかインストールされていないようなので)。

64bit OS だからダメなの?

問題のWPF ブラウザーアプリケーションのビルド構成なども確認したが、Any CPU、すなわち 32bit 環境 でも 64bit 環境でも (そしておそらくは ARM でも?) 問題なく動作するはずの構成でビルドされている。

IEは 32bit 版と 64bit 版が別々にあるが...

Internet Explorer 10 は、32bit 版と 64bit 版は別々の .exe ファイルとして Win8 Pro x64 に同梱されている。
各々 C:\Program Files(x86) および C:\Program Files 以下から個別に起動して、32bit/64bit の両方で試したが、不具合はいずれも変わらずだった。

Win8 にもホストの EXE ファイルはちゃんとある

まさか、WPF ブラウザーアプリケーションは、もう Windows8 では使えないの? と焦ったが、WPF ブラウザーアプリケーションのホスト本体である PresentationHost.exe は、ちゃんと C:\Windows\System32 の下にあった。
しかもご丁寧に、C:\Windows\SysWOW64 にもあった。
ちゃんと 32bit/64bit 版のいずれでも動作するように配慮されていることすらうかがえる。

解決は「管理者として実行」

ネットで検索してもよくわからず途方に暮れていたのだが、ふと、IE を管理者モードで実行したらどうなるか、ということを突然思いついた。

IE デスクトップ版は、デスクトップ画面のタスクバーにピン止めしてあるのでこれを右クリック。
出てきたコンテキストメニューから「管理者として実行」を選択して IE を起動する。

こうして管理者モードで起動した IE から、当該 WPF ブラウザーアプリケーションへのリンクをたどっていくと、無事、いつもどおり平常に起動・利用することができた。

追記
管理者モードで実行するにはキーボードコンビネーション付のマウスクリックでもできるそうだ。

@jsakamoto すっごくどうでもいいTipsですが、Ctrl+ShiftでEXEクリックすると管理者権限で実行できますよ。コンテキストメニューから選択するより個人的に重宝しています。 / “Win7 Pro(x86) で動いてい…” htn.to/GrFBGg

— naoki0311さん (@naoki0311) 9月 21, 2012

完全信頼だからなのか...?

今回問題となった WPF ブラウザーアプリケーションは、先に書いたように完全信頼モデルを要求する。

これが原因で、IE が管理者モードで実行されていないとだめなのだろうか?
部分信頼モデルの WPF ブラウザーアプリケーションは作っていないため、実際のところどうなのか確かめることはできていない。

また、Windows7 Pro x86 では管理者モードでなくても実行できていたのが気になる。
Windows8 になってなにかセキュリティ上の仕様か何かが微妙に変わっているのかもしれない。
これまでの現象から推測するに、32bit か 64bit かは関係なさそうだ。

はっきりした原因・発生メカニズムまで理解が及んでいないが、とりあえず現象面、回避策としては、IE を「管理者として実行」すれば良いことまではわかった。

ただし IE を「管理者として実行」させることは、社内運用上、ユーザーへの告知など、けっこう不便だ。
WPF ブラウザーアプリケーションはあきらめて、普通の ClickOnce アプリに仕立てたほうがいいかもしれない、と考え始めている。