2012年11月22日木曜日

IE で VBScript が動かない!?

かつて、ブラウザの対話性向上の切り札として幅広く利用された Java アプレットという技術がありました。Write once, run anywhere をスローガンに、幅広いプラットフォームでの実行可能性を秘めた Java は当時の IT バブルの波に乗り、ウォール街では「すべてが Java で書き換えられる。数年以内にマグナカルタでさえも Java で書き換えられるだろう」などと言われたそうです。

ちょうどそのころ、Windows 95 と Office 製品の爆発的大ヒットに支えられたマイクロソフトは、同社の Internet Explorer 向けの対話性向上技術として ActiveX コンポーネントをリリースしました。ActiveX コンポーネントは Windows 向けの RAD 開発環境として幅広く支持された Visual Basic でも開発できたため、主に Office のマクロ開発環境として利用されていた Visual Basic for Applications (VBA)や、IE 上で動作するスクリプト言語である VBScript と合わせ、Microsoft プラットフォーム上では Visual Basic 系言語が全盛時代を迎えます。レッドモンドでは「合衆国憲法だって BASIC で書ける。そう、Bill Gates ならね」などと言われたとか、言われなかったとか。

余談ですが、ActiveX はマーケティング用語として登場しただけの話であって、要は OLE 、もう少し低レベルでいうと COM のことでした。IDispatch インターフェイスをサポートした COM コンポーネントは、Visual Basic、VBA、VBScript から利用する事が出来ました。

また、VBScript は ActiveX スクリプティング(Active スクリプト)をサポートするスクリプト言語のひとつとして実装されました。実際には IE や Windows Scripting Host(WSH)、Active Server Pages (ASP)といった実行環境上で動作する共通ランタイムの上に VBScript インタープリタが実装されており、同ランタイム上には Microsoft 版の JavaScript である JScript インタープリタも実装されていました。この「実行環境と実装言語を切り離す」という考え方は、現在の .NET 環境にも脈々と受け継がれている気がします。

ActiveX という言葉は完全に死語になりましたが、その膨大な資産は今でもサポートされ続けています。

あれから 20 年近くを経た現在、Microsoft プラットフォームでの主なソフトウェア開発環境は .NET Framework にとってかわられ、往年の Visual Basic の地位は C# にとってかわられようとしています(もちろん、Visual Basic も .NET 環境で動作しますが)。

ふと、手元の Windows Phone での旧 VB 系に対するサポートが気になったので、調べてみたところ、以下の文書がヒットしました。

Web development for Windows Phone

そう、Windows Phone 上の IE (IE 9 がベース)では、VBScript はサポート対象外なのです。

以下のような静的 Web ページを作ってテストしてみました。

   1: <html>
   2:     <head>
   3:         <title>タイトル</title>
   4:         <script language="vbscript">
   1:  
   2: Sub Test()
   3:  
   4:     document.getElementById("target").innerText = "うまくいったね!"
   5:     window.alert "テスト!"
   6:  
   7: End Sub
   8:         
</script>
   5:     </head>
   6:     <body>
   7:         <p>テスト中です。</p>
   8:         <p id="target">うまくいくかな?</p>
   9:         <input type="button" onclick="Test" value="Test"/>
  10:     </body>
  11: </html>


Windows 7 上の IE 9 では正しく動作しましたが、Windows Phone ではスクリプトはまったく動作しませんでした。


さらに、Windows 8 上の IE 10 でも無反応。デスクトップ版 IE では HTML ソース中に



   1: <meta http-equiv="x-ua-compatible" content="IE=7">


を挿入することで互換表示が強制されて正しく動作しましたが、ストアアプリ版 IE ではまったく無反応のままでした。


クロス ブラウザという観点では全く普及しなかった IE 上の VBScript 利用でしたが、企業内システム(いわゆるイントラネット)向け Web アプリケーションのクライアント側スクリプト言語として利用されたケースがあるかもしれません。残念ですが、これらのアプリケーションは最新 OS ではまともに動作しないことになりそうです。


そもそも JavaScript (JScript)ではなく VBScript を使う理由があったのか?という問題ですし、個人的に業務システムで VBScript を全面的に採用したことはありませんでしたが、唯一、多様な表示(「はい」「いいえ」「キャンセル」などのボタンや各種アイコン)をサポートする MsgBox メソッドだけは捨てがたかったと思います。


今回は C# とはほぼ無縁の話題でした。

2012年11月19日月曜日

CA0055 プラットフォームを統合できませんでした

ポータブル クラス ライブラリ(Portable Class Library)を使用した開発を行っている場合などで、Visual Studio のコード分析(Code Analysis)が CA0055 のエラーを発生させる場合があります。本稿では、このエラーの発生原因と解決方法を説明します。

エラー CA0055 とは

ポータブル クラス ライブラリを使用するコードを Visual Studio を使用してコード分析にかけると、CA0055 のエラーが出る場合があります。

このエラーは、コード分析モジュールが、分析対象のアセンブリのプラットフォームを決定できなかった場合に発生します。

また、エラー CA0055 は多くの場合エラー CA0052 (ターゲットは選択されていませんでした)と同時に発生するようです。

対処法

コード分析モジュールに対して、分析対象のアセンブリのプラットフォームを教えてあげることができれば、このエラーは発生しなくなります。

Visual Studio の GUI を使用して分析対象のアセンブリのプラットフォームを構成することはできませんが、分析対象のプロジェクト ファイル(C# ならば *.csproj ファイル)を直接編集することで、この問題に対処することができます。

コード分析モジュールは起動時に分析対象のアセンブリのパスなどをいわゆるコマンド ライン引数として受け取っており、このコマンド ライン引数に追加する内容をプロジェクト ファイル内で指定することができます。

ポータブル クラス ライブラリを使用する側のプロジェクト ファイルを以下の例のように編集します。

   1: <RunCodeAnalysis>true</RunCodeAnalysis>
   2: <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
   3: <CodeAnalysisAdditionalOptions>/platform:"C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\mscorlib.dll"</CodeAnalysisAdditionalOptions>

1 行目は、コード分析を実行するかどうかを指定しています。この値が false ならばコード分析は実行されないので、必然的に CA0055 のエラーも発生しなくなります。

2 行目は、コード分析モジュールが使用するルール セットです。この値は Visual Studio の GUI で変更できるので、特に手動で変更する必要はないでしょう。

3 行目が、今回のポイントです。CodeAnalysisAdditionalOptions タグは、その名の通りコード分析モジュールに対する追加のオプションを指定するために存在します。そこに、分析対象のアセンブリのプラットフォームで使用される mscorlib.dll へのパスを指定します。

コマンド ライン引数の使用は「/platform:(mscorlib.dll へのフルパス)」です。上述の例では、分析対象のアセンブリのプラットフォームが Silverlight 5 であることを指定しています。自身の環境に合わせて指定してください。

なお、/platform オプションは一回のみ指定することができます。また、CodeAnalysisAdditionalOptions タグの中で /d オプションなどと同時に指定することも可能ですから、「CA0060 間接的な参照のアセンブリが見つかりませんでした」や「CA0058 参照アセンブリが見つかりませんでした」への対処と同時に対処することも可能です。


まとめ


コード分析モジュールの CA0055 のエラーは、多くの場合 CA0052 と同時に発生し、コード分析モジュールが分析対象のアセンブリのプラットフォームを決定できなかったことを示しています。


コード分析モジュールが分析対象のアセンブリのプラットフォームを決定できるように、プロジェクト ファイルを編集してコード分析モジュールに対する追加オプションを指定することにより、このエラーを発生させることなく、正しいコード分析を実行できるようになります。

CA0058 参照アセンブリが見つかりませんでした

ポータブル クラス ライブラリ(Portable Class Library)を使用した開発を行っている場合などで、Visual Studio のコード分析(Code Analysis)が CA0058 のエラーを発生させる場合があります。本稿では、このエラーの発生原因と解決方法を説明します。

エラー CA0058 とは

ポータブル クラス ライブラリを使用するコードを Visual Studio を使用してコード分析にかけると、CA0058 のエラーが出る場合があります。

このエラーは、CA0060 の警告とよく似ていますが、CA0060 が「間接的に」参照しているアセンブリを見つけられなかった場合に発生する(コード分析は継続できる)のに対し、CA0058 は「直接的に」参照しているアセンブリを見つけられなかった場合に発生する(コード分析を継続できない)ので、きちんと対処する必要があります。

対処法

上述の通り、参照が間接的か直接的かという違いのみで、コード分析モジュールが必要とするアセンブリのありかを教えてあげれば対処できます。

詳細な対処方法は、「CA0060 間接的な参照のアセンブリが見つかりませんでした」を参照してください。

まとめ

コード分析モジュールの CA0058 のエラーは、コード分析モジュールがコード分析に必要なアセンブリを見つけられなかったことを示しています。

CA0060 間接的な参照のアセンブリが見つかりませんでした」で説明しているように、コード分析モジュールが必要なアセンブリを見つけられるように、プロジェクト ファイルを編集してコード分析モジュールに対する追加オプションを指定することにより、このエラーを発生させることなく、正しいコード分析を実行できるようになります。

CA0060 間接的な参照のアセンブリが見つかりませんでした

ポータブル クラス ライブラリ(Portable Class Library)を使用した開発を行っている場合などで、Visual Studio のコード分析(Code Analysis)が CA0060 の警告を発生させる場合があります。本稿では、この警告の発生原因と解決方法を説明します。

警告 CA0060 とは

ポータブル クラス ライブラリを使用するコードを Visual Studio を使用してコード分析にかけると、CA0060 の警告が出る場合があります。

例えば、ポータブル クラス ライブラリ プロジェクトで System.Xml を参照しており、このプロジェクトを参照する Silverlight 5 プロジェクトも System.Xml を参照しているとします。この時、Silverlight 5 プロジェクトが参照している System.Xml は Version 5.0.5 ですが、ポータブル クラス ライブラリ プロジェクトが参照している System.Xml は Version 2.0.5 だったりします。コード分析モジュールは分析のために Version 2.0.5 の System.Xml を要求するようですが、コード分析モジュールがこのアセンブリを見つけることができなかった場合に、CA0060 の警告がコード分析モジュールから発せられます。

CA0060 の警告はコード分析の結果として報告される警告ではなく、コード分析モジュール自身の動作についての警告なので、プロジェクト抑制ファイル(GlobalSuppressions.cs)等でこの警告を抑制することはできません。

対処法

根本的な問題はコード分析モジュールが必要なアセンブリを見つけることができないことにあり、コード分析モジュールが必要とするアセンブリのありかを教えてあげることができれば、この警告が出なくなるはずです。

Visual Studio の GUI を使用してコード分析モジュールに対して必要なアセンブリのありかを構成することはできませんが、分析対象のプロジェクト ファイル(C# ならば *.csproj ファイル)を直接編集することで、この問題に対処することができます。

コード分析モジュールは起動時に分析対象のアセンブリのパスなどをいわゆるコマンド ライン引数として受け取っており、このコマンド ライン引数に追加する内容をプロジェクト ファイル内で指定することができます。

ポータブル クラス ライブラリを使用する側のプロジェクト ファイルを以下の例のように編集します。

<RunCodeAnalysis>true</RunCodeAnalysis>
<CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisAdditionalOptions>/d:"C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0"</CodeAnalysisAdditionalOptions>

1 行目は、コード分析を実行するかどうかを指定しています。この値が false ならばコード分析は実行されないので、必然的に CA0060 の警告も発生しなくなります。



2 行目は、コード分析モジュールが使用するルール セットです。この値は Visual Studio の GUI で変更できるので、特に手動で変更する必要はないでしょう。



3 行目が、今回のポイントです。CodeAnalysisAdditionalOptions タグは、その名の通りコード分析モジュールに対する追加のオプションを指定するために存在します。そこに、コード分析時に必要になると思われるアセンブリ(警告メッセージで指定されたアセンブリ)が含まれているフォルダのパスを指定します。



コマンド ライン引数の仕様は、「/d:(参照モジュールのパス)」です。上述の例では、ポータブル クラス ライブラリ 4.0 のパスを指定しています。ポータブル クラス ライブラリ 4.5 を使用している場合は、パスの最後が v4.5 になると思います。自身の環境に合わせて指定してください。



なお、/d オプションは複数回指定することができます。コード分析に必要なアセンブリが複数のフォルダに分散している場合などは、CodeAnalysisAdditionalOptions タグの中に /d オプションを複数続けて書くことで対処できるようです。



まとめ



コード分析モジュールの CA0060 の警告は、コード分析モジュールがコード分析に必要なアセンブリを見つけられなかったことを示しています。



コード分析モジュールが必要なアセンブリを見つけられるように、プロジェクト ファイルを編集してコード分析モジュールに対する追加オプションを指定することにより、この警告を発生させることなく、正しいコード分析を実行できるようになります。

2011年1月1日土曜日

新年の抱負

明けましておめでとうございます。

早いもので 21 世紀ももう 10% が経過してしまいました。おいらもこの春から小学校 32 年生になります。

早速ですが、おいらの今年の抱負は 2011 年はきちんとブログのメンテナンスをしよう、ということにしました。

今後は仕事や日常の情報収集の成果をカテゴリ別にブログ エントリとして掲載していこうと思います。もちろんつまらん独り言も合わせて。

で、過去の記事をバッサリ捨て (というほどエントリもありませんでしたが) 、さらにブログ乱立という暴挙に出てみました。

いわゆる .NET Framework 向け開発全般の話題を中心とした内容はこのブログで、システムのドキュメンテーションに関する話題は「システム開発文書研究所」で、システムのインストールに関する話題は「Windows Installer 研究所」で、それぞれ展開していきますよ。サブ ブログのタイトルが「研究所」ってのが、偉そうで好き (笑) 。

では本年もよろしくお願いいたします。