@jsakamoto

.NET Core 3.0 の単一実行可能ファイル生成を手なずける

.NET Core 3.0 の単一実行可能ファイル生成

先日、公式リリースとなった .NET Core 3.0。

その新機能のひとつとして「単一ファイルの実行可能ファイル」を発行する機能がある。

これまでは、C# や VB、F# など .NET Core プラットフォームのプログラムをビルド・発行した場合、その最終成果物は、各種 .dll ファイル群がごちゃっと発行先フォルダに出力されるだけであった。

それが、.NET Core 3.0 の新機能「単一実行可能ファイル生成」を用いると、発行先フォルダには、たったひとつだけの実行可能ファイルが生成されるだけとなり、配布などの取り扱いが容易になる。

(なお、本機能の動作原理は、たとえて言うならば tar のような、どうやらある種の "アーカイブ" として必要 .dll ファイル群を単一実行可能ファイル内に収録しているようである)

もっとも、これまでも ILMerge や ILRepack などなど、.NET プラットフォームのバイナリを単一ファイルにまとめる手法やツールは存在していた。

とはいえ、.NET Core SDK 本体に類似の機能が標準で搭載されており、すぐに使える点は大変便利である。

ということで、Windows OS 上で Visual Studio 2019 を使った開発体制にて、「単一実行可能ファイル生成」を実際に試してみた。

まずは動作を確認

まずは試しにということで、Visual Studio 2019 のプロジェクトテンプレートから .NET Core コンソールアプリケーション (今回は言語は C#) を生成。

"Hello World" を表示するだけの C# プログラムだ。

そして下記記事を参考に、.csproj ファイルに2行書き加えてみる。

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>

<OutputType>Exe</OutputType>

<TargetFramework>netcoreapp3.0</TargetFramework>

<PublishSingleFile>true</PublishSingleFile>

<RuntimeIdentifier>win10-x64</RuntimeIdentifier>

</PropertyGroup>

</Project>

まずはここまででビルドして実行してみる。まぁ、普通に成功することを確認。

続けて、いよいよ発行である。

Visual Studio 2019 上の開発作業ということで、Visual Studio 上でフォルダへの発行プロファイルを作成し(下図)、発行を実行。

すると、手順どおりにやっているのだから当たり前であるが、無事、発行先には .exe ファイルがひとつだけ生成された。(実行環境に 64bit Windows10 OS を指定しているので、生成される実行可能ファイルは拡張子 .exe の PE ファイルである。)

なお、たかが "Hello World" を表示するだけのコンソールアプリケーションであるが、その実行可能ファイルのサイズは 65.8MB になってしまった。

まぁ、ターゲットランタイムがポータブルでない、且つ、配置モードが自己完結 (Self-Contained) な発行成果物を、非圧縮でアーカイブしているだけのようなものなので、こんなものだろう。

他の OS 用にも発行できる

なお、.NET Core といえばクロスプラットフォームである。

ということで、上記プロジェクトを、例えば 64bit Linux 用に単一実行可能ファイルを発行したい場合はどうするか?

これはもう、何も難しいことはない。

ただただ単純に、ターゲットランタイムとして "linux-64" を指定した発行プロファイルを作成して、その発行プロファイルで発行すれば良いだけである (下図)。

だがしかし、そのプロジェクト、Windows 専用になってない?

さてところで、上記までの手順だと、プロジェクトファイル内にターゲットランタイム指定が記載されているため、発行ではなくビルドの時点でも、64bit Windows10 用のバイナリを吐くように規定されてしまっている。

このようなプロジェクトファイルを、Linux や macOS など他の OS 上でビルドするとどうなるか?

まぁ、実はビルドは成功する。

だが、さすがに実行まではできない。

(※実は、Windows10 上の Windows Subsystem for Linux, いわゆる WSL の中だと実行できてしまったりもするのだが、それはまた別の話。)

かといって、ターゲットランタイムの指定をプロジェクトファイル内から記述削除し、ポータブル形式でてビルドしようとしても、今度はビルドが下記エラーで失敗するようになってしまう。

error NETSDK1097:

RuntimeIdentifier を指定せずにアプリケーションを単一ファイルに発行することはサポートされていません。

RuntimeIdentifier を指定するか、PublishSingleFile を false に設定してください。

".NET Core といえばクロスプラットフォームである" といっておきながら、これはいただけない。

どうしたものか?

発行プロファイルで指定する

答えは

「単一実行可能ファイル生成の指定は、プロジェクトファイル (.csproj) に書かない。代わりに発行プロファイル (.pubxml) に書く。」

である。

Visual Studio で開発していての発行プロファイルとは、その実態は、Properties フォルダ以下に配置された拡張子 .pubxml のファイルであり (下図)、プロジェクトファイル (.csproj) に対する差分である。

ということで、まずは .csproj ファイルからは、先ほど追加した単一実行可能ファイル生成およびターゲットランタイム指定の2行を削除して、元に戻す。

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>

<OutputType>Exe</OutputType>

<TargetFramework>netcoreapp3.0</TargetFramework>

</PropertyGroup>

</Project>

次に、先に作成していた発行プロファイルを (Visual Studio の発行プロファイル編集 GUI 経由ではなく) エディタで開いて直接編集し、"<PublishSingleFile>true</PublishSingleFile>" の行を追加する。

(※ターゲットランタイム指定 ("<RuntimeIdentifier>～</RuntimeIdentifier>") は既に含まれているはず)

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup>

...

<RuntimeIdentifier>win10-x64</RuntimeIdentifier>

<PublishSingleFile>true</PublishSingleFile> <!-- ← これを追記 -->

</PropertyGroup>

</Project>

以上で OK だ。

これでこのプロジェクトは、どの OS 上であっても、ターゲットランタイム = ポータブルとしてビルド・デバッグ実行可能となる。

その上で、上記発行プロファイルを使って発行すれば、64bit Windows 10 上で直接実行可能な (.NET Core Runtime の事前インストールも不要な) 単一ファイルの実行可能ファイルが手に入る。

もちろん、他の OS 用に発行プロファイルを変更したり発行プロファイルを追加したりしてもよい。

補足1 - dotnet CLI での開発時

冒頭で示した公式ドキュメントを見ると、dotnet CLI を使う場合は、dotnet CLI 実行時のコマンドライン引数に、ターゲットランタイム指定と、単一実行可能ファイル生成指定を行なう方法が説明されている (下記例)。

> dotnet publish -r win10-x64 /p:PublishSingleFile=true

このように、やはりプロジェクトファイル内では単一実行可能ファイル生成の指定はせず、発行時に個別に単一実行可能ファイル生成の指定を行なう (この例で言えば、dotnet CLI のコマンドライン引数で指定する) のがよさそうである。

また、dotnet CLI を使った場合でも下記要領にて、今回説明したような発行プロファイルを用いた発行をすることもできる。

dotnet publish /p:PublishProfile=<ここに.pubxmlファイルのパス>

補足2 - Visual Studio 2019 の発行プロファイル編集 GUI がおかしい

ここまでわざと気づかぬフリをしてきたが、実はここまで説明してきた手順だと、本記事のスクリーンショットにもちょっと見えているが、Visual Studio 2019 の発行プロファイル編集 GUI の表示上は、配置モードが「フレームワーク依存」と表示されてしまっている。

しかし実際に発行される内容は、配置モード = 「自己完結」 (Self-Contained) な内容となっている。

実はこれ、ターゲットランタイム指定 (RuntimeIdentifier) が指定されていると、配置モード指定が明示的に設定されていない場合、どうやらビルドスクリプト上は配置モードのデフォルト値が、「フレームワーク依存」から「自己完結」に切り替わっているようなのである。

ただ、そのビルドスクリプトの仕様が Visual Studio 2019 の発行プロファイル編集 GUI には反映されていないようで、すなわち、Visual Studio 2019 の発行プロファイル編集 GUI では、配置モードの指定が明示的に設定されていない場合は「フレームワーク依存」と表示されているようだ。

ぐだぐだ書いたが、このような混乱を避けるには、配置モード指定を発行プロファイル内に明記してしまえばよい。

...

<SelfContained>true</SelfContained> <!-- ← これを明記 -->

</PropertyGroup>

</Project>

あるいは Visual Studio 2019 の発行プロファイル編集 GUI 上で、配置モードを明示的に「自己完結」に選択し直しておいても OK だ。

このように常に配置モードの指定を明示的に設定しておくようにすれば、要らぬ混乱を避けられるであろう。

なお、この逆に、配置モードを「フレームワーク依存」として明示的に設定して単一実行可能ファイル生成指定で発行したらどうなるか?

そうすると、OS に別途 .NET Core ランタイムの事前インストールが必要となるが、サイズは極小となる、そのような単一実行可能ファイルが発行先に生成される。

.NET Core SDK がインストール済みであることが前提な開発者向けのツールなど、これはこれで需要あるかもしれない。

まとめ

単一実行可能ファイル生成は、その機能の性質上、ターゲットランタイムの指定が必須である。

そのため、単一実行可能ファイル生成の指定は、プロジェクトファイルに記入するのではなく、発行プロファイルに記入しておくのが、自分的にはお勧めである。

[2019/12/29 追記]

Visual Studio 2019 v.16.4.2 で発行プロファイル編集の GUI を開いたところ、[単一ファイルの生成] チェックボックスが増えていた!

このチェックを On にすると、本記事で示したように、発行プロファイル (.pubxml) 中に "<PublishSingleFile>true</PublishSingleFile>" が書き込まれる。

もちろん、.pubxml を直接エディタで編集しても何ら問題ないが、このように GUI 上でも設定できるのはやはり便利である。

.NET Core 2.0 アプリで JIS 形式 (iso-2022-jp) なメールを SmtpClient で送信する

C# などを使い、.NET Core ランタイム上で動作する .NET Core 2.0 なアプリ (ASP.NET Core 含む) を開発していての話。

そのようなアプリ開発で、JIS (iso-2022-jp) エンコードなメールを、System.Net.Mail.SmtpClient を使って送信するにはどうしたらよいか、というのが今回のテーマである。

もっとも、イマドキ、アプリからのメール送信の需要は衰退の一途のような気がする (通知なら Slack や LINE、Skype などへの Bot 投稿で実装するほうがよい?)。
仮にメール送信の需要が発生したとしても、SendGrid の Web API 叩いたり、Microsoft Azure の LogicApps サービスを使ったりしてメール送信を実装したほうがよさげなので System.Net.Mail の出番はなさそうだ。
ましてや今更 JIS エンコードなメールなどほとんど絶滅危惧種ではないかとも思われる。

が、とりあえずそのような要件が発生してしまい、実装に着手したものとする。

標準の文字エンコーディング情報では不足

この場合は、下記のようなコード (例は C#) で実現するのがよくある実装かと思う。
using System.Text;
using System.Net.Mail;
...
var iso2022jp = Encoding.GetEncoding("iso-2022-jp");
var msg = new MailMessage
{
BodyEncoding = iso2022jp,
SubjectEncoding = iso2022jp,
HeadersEncoding = iso2022jp
};このコードは、旧来からある .NET Framework 用アプリでは問題なく動作する。

しかしながら、.NET Core 用アプリでは実行時に下記例外が発生してしまう。System.ArgumentException : 'iso-2022-jp' is not a supported encoding name. 発生個所は「Encoding.GetEncoding("iso-2022-jp")」しているところ。
.NET Core ランタイムでは、標準の文字エンコーディング情報に、JISエンコーディングが含まれていないためだ。

この例外への対処は簡単である。

まず NuGet から System.Text.Encoding.CodePages パッケージをプロジェクトに追加してやる。

System.Text.Encoding.CodePages

あとはアプリの初期化のタイミングで、上記パッケージに収録されているエンコーディング情報をランタイムに登録してやればよい。using System.Text;
...
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);System.Text.Encoding.CodePages パッケージには JIS (iso-2022-jp) エンコーディング情報も収録されている。
よって、上記仕掛けを施したあとは、「Encoding.GetEncoding("iso-2022-jp")」でちゃんと Encoding オブジェクトが返ってくるようになる。

参考: OPC Diary - dotnet coreで対応しているテキストエンコーディング

System.Text.Encoding.CodePages でも不足の点が

ところが、である。

たいていの文字エンコーディングを扱う .NET Core プログラムにおいてはこれで問題解消となるのだが System.net.Mail.SmtpClient を使ったメール送信では、この対処だけではまだ足りない。

Send メソッド実行時に下記例外が発生して、相変わらず JIS (iso-2022-jp) エンコーディングでのメール送信ができないのだ。System.NotSupportedException : No data is available for encoding 50220. この例外のスタックトレースを見てみると、at System.Text.Encoding.GetDataItem()
at System.Text.Encoding.get_BodyName()となっている。

どうも、Encoding オブジェクトの BodyName プロパティの getter で例外発生しているようだ。

念のため Visual Studio 上でブレークポイントを張って問題個所の前で停止させて、JIS エンコーディングのオブジェクトを見てみると、下図のとおり。ご覧のとおり、BodyName プロパティの参照で System.NotSupportedException 例外が発生している (BodyName プロパティに限らないが)。

他に Shift-JIS と euc-jp についても確認してみたところ、いずれも BodyName プロパティ参照で System.NotSupportedException 例外が発生した。

参考までに、ランタイム標準で備わっている UTF-8 (Encoding.UTF8) については、BodyName プロパティは、ちゃんと "utf-8" を返す。

どうやら、System.Text.Encoding.CodePages パッケージで供給される追加のエンコーディング情報、少なくとも上記 JIS, Shift-JIS, EUC-JP については、BodyName プロパティがサポートされていないようである。

いっぽうで System.Net.Mail.SmtpClient は Encoding オブジェクトの BodyName プロパティに依存しているようだ。
それで前述のとおり JIS エンコードなメールを送信しようとすると例外発生に至ってしまうらしい。

ラッパークラスを実装して回避

System.Text.Encoding.CodePages パッケージで供給される追加のエンコーディング情報について、なぜに BodyName プロパティがサポートされていないのか自分はわかっていない。

しかしとにかく、問題のメカニズムは判明したので自前の回避策は実装可能だ。

自分が実施した回避策は、
「BodyName プロパティを正しく返すよう補完実装した、Encoding から派生したラッパークラスを実装する」
という作戦。

使い方としては、まず、オリジナルの Encoding オブジェクトを、このラッパークラスのオブジェクトで包んでおく。
そして、そのラッパー Encoding オブジェクトを System.Net.Mail に教えてやる、という寸法だ。

このラッパークラスは、外部からのあらゆる問い合わせを、内包しているオリジナルの Encoding オブジェクトに横流しするだけにしておく。
ただし、オリジナルの Encoding オブジェクトが答えられない、BodyName プロパティについてだけは、オリジナルに代わってラッパークラスが返答する、という仕組みにするわけ。


ということで、そのようなラッパークラス "BodyNamePatchedEncoding" クラスを書いてみた。
下記に置いてある。

https://gist.github.com/jsakamoto/87d5b76387d8287ba6cea0362777c206

このラッパークラスの実装に面白いところは全くない。

このラッパークラスのコンストラクタで、ラップする対象の Encoding オブジェクトと、BodyName プロパティ値を受け取り、このふたつをインスタンスメンバーに保持。

あとは、Encoding オブジェクトとして必要なふるまい・プロパティ値は、メンバーに保持しているラップ対象の Encoding オブジェクトに丸投げするだけ。
ただし、BodyName プロパティだけは、コンストラクタで指定された値を返す。

BodyNamePatchedEncoding クラスの実装コードは行数がなかなかのボリュームになっている。
しかしそのほとんどが前述のとおり、ラップしている Encoding オブジェクトへ処理を横流ししているだけの、刺身タンポポ感たっぷりのコードだ。


なお、実際に BodyNamePatchedEncoding クラスを実装して System.Net.Mail.SmtpClient による JIS エンコーディングなメール送信を試したところ、最初はまたもや例外となった。
その例外の内容を見ると、どうやら SmtpClient は BodyName プロパティのみならず HeaderName プロパティも 参照してる模様。
且つ、HeaderName プロパティも System.Text.Encoding.CodePages パッケージの実装ではサポートされておらず、それでまたもや例外となったようである。
そこで、HeaderName プロパティについても BodyNamePatchedEncoding クラスがオリジナルに代わって返答することとし、返答の内容は、実装の手を抜いて、BodyName プロパティと同値を返すようにした。


以上で、この BodyNamePatchedEncoding クラスを使えば、晴れて、.NET Core アプリでの System.Net.mail.SmtpClient にて JIS エンコーディングなメール送信が実現できるようになった。using System.Text;
using System.Net.Mail;
...
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
...
var iso2022jpOriginal = Encoding.GetEncoding("iso-2022-jp");
var iso2022jpWrapped = new BodyNamePatchedEncoding(
encoding: iso2022jpOriginal,
bodyName: "iso-2022-jp");
var msg = new MailMessage
{
BodyEncoding = iso2022jpWrapped,
SubjectEncoding = iso2022jpWrapped,
HeadersEncoding = iso2022jpWrapped
};

まとめ

.NET Core では、ランタイムが標準で提供している文字エンコーディングはかなり限定されている。

不足のエンコーディング情報が必要な場合は、System.Text.Encoding.CodePages パッケージをプロジェクトに追加して、追加されたエンコーディング情報をランタイムに登録すればよい。

しかし System.Text.Encoding.CodePages パッケージで提供される Encoding クラスの実装では、BodyName プロパティや HeaderName プロパティなどサポートされていない機能がある。

.NET Core の System.Net.Mail.SmtpClient は Encoding オブジェクトの BodyName および HeaderName プロパティを使用するので、System.Text.Encoding.CodePages パッケージで提供される Encoding クラスを指定してのメール送信では例外が発生してしまう。

これを回避する一案としては、実装が不足している機能を補うラッパー Encoding クラスを自前実装することで可能であり、実際に BodyNamePatchedEncoding クラスを実装してみて、無事メール送信に成功した次第。

補足

System.Text.Encoding.CodePages パッケージで提供される Encoding クラスの実装では、なぜ BodyName プロパティなどがサポートされていないのか、その理由が気になるところではある。
どのような設計指針・方針でサポートしないこととなったのだろうか、あるいはまた、System.Text.Encoding.CodePages パッケージの将来バージョンでは、これら機能の実装も追々追加されるのか、要注意ではあると思う。


あともうひとうつ別の話題として、ここまでの実装だと、どこか別の箇所で "Encoding.GetEncoding("iso-2022-jp")" などと Encoding オブジェクトの取得を行った場合は、相変わらず、BdoyName プロパティが機能しないオリジナル版の Encoding オブジェクトが返されることになる。

"Encoding.GetEncoding("iso-2022-jp")" を実行時も、BodyNamePatchedEncoding オブジェクトが返されるようにするには、もうひと手間必要だ。
言い換えると、もうひと手間必要ではあるが、しかしとにかく実装可能ではある。

その方法については、また機会を改めたい。
　

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 アプリに仕立てたほうがいいかもしれない、と考え始めている。

自作.NETアプリに、Ruby や Python によるマクロ機能を搭載する

IT コミュニティ CLR/H の第63回勉強会では、マイクロソフト・荒井省三さんによるセッションにて、DLR ( Dynamic Language Runtime: 動的言語実行環境 ) にまつわるお話しを頂いた。

そのおさらいと成果を報告。

マクロ機能

Microsoft Office 製品には、"VBA" ( Visual Basic for Application ) というプログラミング言語が搭載されており、このプログラミング環境を用いることで、Word や Excel などに機能追加したりすることができる。

このように、何らかの簡易なプログラミング言語を内蔵して、そのアプリ自身に機能追加することを容易にする仕組みは、少なからず見かける。

ここではそのような機能のことをマクロ機能と呼ぶことにする。

そこで、CLR/H 第63回勉強会での成果を活かして、自作する .NET アプリにマクロ機能を搭載するチュートリアルに臨んでみた。

お題

メモ帳のような WPF アプリ = Notepad1 を作成、この Notepad1 を IronRuby で書いたスクリプトコードによって機能追加できるようにする。

アプリ本体の開発

下図のような WPF アプリ、Notepad1.exe を作成しておく。メインウィンドウに、Menu と TextBox を配置しただけ。

あと、このあとのマクロ機能の実装で、言語として IronRuby を使うので、nuget.org 経由で IronRuby の NuGet パッケージをプロジェクトに追加する。

IronRuby - NuGet Package
https://www.nuget.org/packages/IronRuby/

具体的には、例えば、Visual Studio のパッケージ管理コンソールから以下のコマンド入力すればよい。

PM> Install-Package IronRuby

すると、nuget.org から IronRuby の NuGet パッケージがダウンロードされ、下記アセンブリ ( .dll ) が参照設定に追加されるのがわかるだろう。

• IronRuby
• IronRuby.Library
• Microsoft.Scripting

マクロ機能の仕様

下図のようなフォルダ構造とする。Notepad1.exe があるフォルダ以下に "Macros" サブフォルダを作成しておく。

この Macros サブフォルダ内に配置しておいた Ruby スクリプト ( .rb ) を実行時に読み込んで、Notepad1.exe の [マクロ(M)] メニューから呼び出すようにする。

Macros サブフォルダ内の .rb ファイルのファイル名がそのまま Notepad1.exe の [マクロ(M)] メニューのメニューアイテムとして表示される寸法だ。

構成ファイルの設定

アプリ内から IronRuby スクリプトを実行する準備として、今回は構成ファイルにいくつか設定を施しておくことにする。
下記のとおり、microsoft.scripting 構成セクションを認識できるよう、構成セクションハンドラを仕込んでおく。

その上で、microsoft.scripting 構成セクションに、このアプリに搭載されるスクリプト言語やそのスクリプトファイルの拡張子などを設定しておく。

<configuration>

　<configSections>

　　<section name="microsoft.scripting"

　　　requirePermission="false" 

　　　type="Microsoft.Scripting.Hosting.Configuration.Section, Microsoft.Scripting"/>

　</configSections>



　<microsoft.scripting>

　　<languages>

　　　<language

　　　　extensions=".rb"

　　　　displayName="IronRuby"

　　　　type="IronRuby.Runtime.RubyContext, IronRuby"

　　　　names="IronRuby;Ruby;rb"/>

　　</languages>

　</microsoft.scripting>

　...

[マクロ(M)] メニューの実装

[マクロ(M)] メニューアイテムに予めダミーのサブメニューアイテムを追加しておく。

すると、[マクロ(M)] メニューが開かれるときに SubmenuOpened イベントが発生するのでこれをハンドル。

SubmenuOpened のタイミングで Macros フォルダ内のスクリプトファイルを列挙し、ファイル名のメニューアイテムを追加していく。

このメニューアイテムに、"MacroCommand" という自作のコマンドを関連付けし、コマンドのパラメータとしてスクリプトファイルのフルパスを格納しておく。

"MacroCommand" の実装

...と、まぁ、ここまでは下準備。

以上の実装により、[マクロ(M)] メニュー以下、スクリプトファイル名のメニュー項目が選択されたら、”MacroCommand" という自家製のコマンドが、スクリプトファイルのフルパスを引数に伴って発火することになる。

"MacroCommand" の実行を Macro_Executed メソッドにバインドして、この Macro_Executed メソッド内で、引数としてやってきたスクリプトファイルのフルパスからスクリプトコードを読み込んで実行すればよい。

まずはスクリプトファイルのフルパスを取得。

public void Macro_Executed(

　object sender, 

　ExecutedRoutedEventArgs e)

{

　var macroPath = e.Parameter as string;

スクリプトランタイムの生成

次に、スクリプトコードの実行基盤となるスクリプトランタイム ( Microsoft.Scripting.Hosting. ScriptRuntime型 ) のオブジェクトインスタンスを生成する。

スクリプトランタイムオブジェクトの生成には、普通に new するのをはじめ、いくつかやり方がある。
今回は .config 構成ファイルの設定に沿ってスクリプトランタイムオブジェクトを生成する、CreateFromConfiguration 静的メソッドを使った。

var scriptRuntime = ScriptRuntime.CreateFromConfiguration();

言語エンジンの生成

スクリプトランタイムを生成したら、スクリプトランタイムに言語エンジンを生成してもらう。
これまたいくつかやり方が用意されているが、今回は、スクリプトファイルの拡張子から、適切な言語エンジンを生成する、GetEngineByFileExtension メソッドを呼び出すことにした。

var ext = Path.GetExtension(macroPath);

var engine = scriptRuntime.GetEngineByFileExtension(ext);

スコープ

言語エンジンが入手できたら、もう、スクリプトコードをその言語エンジンに与えて実行することができる。

しかしそれだけでは、この Notepad1.exe 自身とはなんの関係もない、独立したプログラムコードが動くだけに過ぎない。

この Notepad1.exe 自身の内部を、これから実行するスクリプトコードでいじれるようにしてやらねば、マクロ機能としては成り立たない。

そこで、"スコープ" という仕組みを使う。

スコープと呼ばれる、ある種の辞書オブジェクトを介して、アプリ側からスクリプトコードへ、名前を付けてオブジェクトを開示するのだ。

まずは "スコープ" オブジェクトを生成する必要がある。

これまたスクリプトランタイムに生成してもらう。

var scope = scriptRuntime.CreateScope();

スコープオブジェクトが手に入ったら、スコープの SetVariable メソッドで、アプリ内のオブジェクトモデルを名前を付けて登録する。
そう、Web ブラウザが HTML DOM オブジェクトモデルを、JavaScript エンジンに引き渡すように。

今回はチュートリアルなので凝ったことはせず、単純に Notepad1.exe に貼り付けた TextBox オブジェクトをそのままスクリプトコードに開示することにした。

scope.SetVariable("textBox", this.textBox1);

これで、スクリプトコード内から "textBox" という名前で、Notepad1.exe に貼り付けた TextBox オブジェクトを操作する準備ができた。

実行

ここまでできたら、ようやく、こうして作成したスコープと、実行するスクリプトファイルの二つを引数に言語エンジンに渡して、スクリプトの実行となる。

engine.ExecuteFile(macroPath, scope);

スクリプトの例

例えば、次の Ruby スクリプトを記述した "To upper case.rb" ファイルを Macros サブフォルダに置いておくと、Notepad1.exe のテキストボックス内に記述した英字がすべて大文字に変換されるマクロ機能を追加できる（メニュー [マクロ(M)]-[To upper case] を選ぶと実行される）。

textBox.set_Text textBox.get_Text.upcase

スコープで開示した WPF の TextBox オブジェクトに、"textBox" という名前でアクセスできているのがわかる。

※IronRuby なので、プロパティへのアクセスには set_プロパティ名/get_プロパティ名のアクセッサメソッド直接呼び出しが必要らしい。要確認。

プロジェクト一式

以上、ソースコード一式を GitHub に公開。

DLR Scripting Sample - Notepad1.zip
https://github.com/sample-by-jsakamoto/DLR-Scripting-Sample-Notepad1/

ソースコードを .zip ファイルに固めたものだけ欲しい場合は下記リンクからどうぞ。
https://github.com/sample-by-jsakamoto/DLR-Scripting-Sample-Notepad1/releases/tag/v.1.0.0.0

IronPython について

すでにお気づきかも知れないが、この Notepad1.exe、IronPython をインストールすれば、Python スクリプトによってマクロ機能を書くこともできる。

.config ファイルの languages セクションに IronPython についてのエントリを書き加え、Macros フォルダに拡張子 .py で Python スクリプトを置けば OK だ。

まとめ

このように、自作アプリに軽量言語によるマクロ機能を追加するのは、容易に行えることがわかった。

今回はチュートリアルということで、WPF の TextBox オブジェクトを直接スクリプトに開示するのみであったが、ちゃんとしたオブジェクトモデルをデザインしてスクリプトに開示することで、そのアプリケーション全体を自由にコントロールさせることができるようになる。
　

独自の TraceListener 実装でそのリスナー独自の構成パラメータを指定するには

.NET アプリ全般的な話。

トレース機能とトレースリスナ

.NET Framework には Trace クラスや TraceSource クラスなどによるトレース機能（ある種のロギング機能といっていいだろう）が備わっている。

アプリ本体側から Trace.Write とかすると、そのアプリケーションに設定されている "トレースリスナ" オブジェクトに引き渡され、各トレースリスナオブジェクトが然るべきところに書き込みを行う、という寸法だ。

たとえば、Windows OS のイベントログに書き込むというトレースリスナが .NET Framework には標準装備されている。
これをアプリにセットアップしておくと、アプリからのトレース出力が、Windows のイベントログに書き込まれるようになる。

アプリへのトレースリスナの組み込みは、コード上から明示的に行えるほか、App.config や Web.config などアプリケーション構成ファイルにて指定することができる。

トレースリスナは自作できる

当然のことながら、トレースリスナは自作できる。

TraceListener クラスから派生した自作クラスを用意し、Write メソッド、WriteLine メソッドを override して実装するだけ。

とは override した Write/WriteLine メソッド内で、好きなようにトレース出力を扱えばよい。

こんな風に、MongoDB に書き込む事例もある。

無聊を託つ - TraceListner into MongoDB
http://takepara.blogspot.com/2011/10/tracelistner-into-mongodb.html

自作トレースリスナにパラメータ指定するには?

さて、トレースリスナを自作する場合、独自のパラメータ指定ができたほうが便利なことも多いだろう。

たとえばトレース出力を片っ端からメール送信するトレースリスナを自作する場合、宛先や件名などを App.config のトレースリスナ設定行に記述しておきたいのではないだろうか。

もちろん、appSettings 構成セクションを使えばお気楽である。
ただ、トレースリスナ設定行とセクションが違うので、設定箇所が離れてしまうのが難点か。
appSettings 構成セクションがどんどん "汚染" されるのも、ちょっといただけない。

ということで実は、.NET Framework はそんな要望にすでに応えており、トレースリスナ設定行に独自パラメータを併記できるようになっていた。

まずアプリケーション構成ファイルのトレースリスナ設定行には、次の要領で独自パラメータを XML 属性として記述しておく。

<system.diagnostics>
<trace>
　<listeners>
　　<add name="MyListener" type="MyListenerClass, MyAssembly" to="foo@bar.com" sibject="wow!"/>
　</listeners>
</trace>
</system.diagnostics>

自作トレースリスナで GetSupportedAttributes メソッドをオーバーライドする。
ここで、独自パラメータ名を返すようにするのだ。

protected override string[] GetSupportedAttributes()
{
　var attrs = new List(base.GetSupportedAttributes() ?? new string[0]);
　attr.Add("to");
　attr.Add("subject");
　return attrs.ToArray();
}

こうしておくと、自作トレースリスナのコード上で、基底クラス TraceListener の Attributes プロパティを参照したときに、独自パラメータを参照できる。

public override void WriteLine(string message)
{
　var to = this.Attributes["to"];
　var subject = this.Attributes["subject"];
　...
}

以上、ご参考まで。
　

CLR/H第63回勉強会ライトニングトーク - OutOfMemoryException 発生を少しでも緩和するために

先日10/15(土)に開催された、CLR/H 第63回勉強会のライトニングトークに、このたびも登壇させて頂いた。

そのときの資料を下記のとおり slidshare に公開。

View more presentations from Jun-ichi Sakamoto

ただし、slideshare ではせっかくのアニメーションが見られない。

そこで、SkyDrive にもアップロードして公開。

http://t.co/Dsxam6Yw

Silverlight が必要だが、きちんとアニメーションも動作するので、わかりやすいと思われる。
　
ちなみに本件で大変参考になったブログ記事はこちら。

torutkの日記 2010-05-29 .NETのメモリ管理と断片化問題
http://d.hatena.ne.jp/torutk/20100529/p1

大変よくまとまっていて、わかりやすい。
　

.NET 上からファイルのウィルス検出と駆除を行う - IOfficeAntiVirus ではなく IAttachmentExecute を使う

Windows OS に限定される話になるが、さて。

Windows にはウィルス対策ソフトとの橋渡しをする API がある?

最近の Windows OS には、インストールされているウィルス対策ソフトを使って、ファイルがコンピュータウィルスでないか・感染していないか、検出（スキャン）するための API が用意されていると聞いた。

※"コンピュータウィルス" という用語は、マルウェアやワームなどは含まないのが本来の意味であるのだろうが、本投稿ではそういったもの一切合切まとめて "ウィルス" と書いてしまってある。ご容赦頂きたい。

実際、Internet Explorer はもとより、Firefox も、インターネット上からファイルをダウンロードしてくると、ダウンロードマネージャ画面にて "スキャン中です" のメッセージとプログレスバーが一瞬表示される。

聞くところによれば、Firefox も、この Windows の API を使って、ウィルス検出を行っているとのこと。

その API というのが、IOfficeAntiVirus COM インターフェースなんだそうだ。

そう、COM インターフェースなのである。

なので、Windows OS の API と言ってしまうと不正確。

すなわち、いろいろなベンダーさんがリリースしていらっしゃるウィルス対策ソフトそれ自身が、IOfficeAntiVirus COM インターフェースを公開・実装しているわけである。

その上で、COM のカテゴリマネージャーから列挙・インスタンス生成できるよう、レジストリに登録しておくわけだ。

Microsoft としては橋渡しをする API を設けたのではなく、共通の規格と標準の手続きを設計・公開して、各ベンダーにそれにのってもらったというところだろう。

.NET から使いにくい & WSH からは使えない

しかし、上記のように COM として用意されている仕組みであり、.NET 上の言語からはなかなか呼び出しにくい。

そもそもある特定の CoClass をインスタンス化すればいいわけではない。

COM のカテゴリマネージャに問い合わせして、列挙してもらう必要がある。
そんな次第なのでタイプライブラリがあるわけでもなく、Visual Studio 上から参照設定とか、tlbimp.exe でインポート、とすることができない。

ツール類の助けを借りることなく、地道に IDL 宣言を C# 言語などに写経する必要があるのだ。

おまけに、.NET 上の言語ならまだしも、VBScript など IDispatch COM インターフェースを利用する、遅延バインディング系の処理系からだともうお手上げである。

IOfficeAntiVirus インターフェースを備える COM コンポーネント ― ウィルス対策ソフト ― が、同じウィルス検出機能を提供する IDispatch インターフェースを備えているとは限らないからだ。

いちおう、ファイルがコンピュータウィルスでないか・感染していないかを、VBScript など WSH 環境から検出するには、Shell API 経由で、ウィルス検出を行う "動詞 (Verb)" を指定して目的のファイルを "実行" する方法もあろう。

いわば、エクスプローラ上でのファイルの右クリックで現れるコンテキストメニューから、「Microsoft Security Essentials でスキャンします」項目を選ぶのと同じ動作だ。

しかしこれでは、呼び出し側にウィルス検出の結果が戻り値としては返らず、また、ユーザーインターフェースの動作が伴うため、バッチ処理には向かないという面がある。

そもそも、インストールされているウィルス対策ソフトの種類が違えば、ウィルス検出を行う "動詞 (Verb)" も異なってくるのではなかろうか。

.NET でラップする!

そこで、IOfficeAntiVirus インターフェースに立脚した、ファイルのウィルス検出を行う .NET クラスライブラリを作成することにした。

.NET のクラスライブラリであれば、C#、VB、F# などの .NET 系のプログラミング言語からの利用はもちろんのこと、Windows PowerShell からも利用できるようになる。

さらに RegAsm.exe コマンドを使ったレジストリへの登録を済ませれば、VBScript や JScript などの WSH 環境からも利用できるのだ。

正常動作しない!?

ということで早速 C# で実装を完了し、Microsoft Security Essentials がインストールされている Win7 Pro (x64) で動作検証してみた。

まずは普通のテキストファイルをスキャンしてみる。
ふむ、S_OK ( 正常 ) が返る。よしよし。

次に、実在しないパス名を与えてスキャン実行してみる。
E_FILE_NOT_FOUND が返るはずだが... あれれ? S_OK が返る。

最後に、テスト用のウィルス、eicar.com を用意して、これをスキャンしてみる。
S_FALSE ( 検出した ) が返るはずだが... またしても S_OK が返る...!

いったいどうなっているのか!?

釈然としないまま、さらに、ESET NOD32 Anti Virus 4 がインストールされている、 Win7 Pro (x86) でも動作確認してみる。

COM カテゴリマネージャーからは、どうやら NOD32 らしきコンポーネントが正しく列挙されてくる。
しかし、これをインスタンス化して IOfficeAntiVirus インターフェースを要求してみると、なんと "そんなインターフェースは実装していない" とエラーになるのだ。

スキャン以前の問題である。

もうわけがわかりません。

IOfficeAntiVirus インターフェースはもう古い?

そこで、冒頭に書いた、Firefox のことを思い出した。

自分の実装ではどうにも正常動作しない。
しかし Firefox はちゃんとウィルス検出をやっているではないか、と。

そこで、Firefox のソースコードを調べてみた。

なんと。

Firefox、というか、Mozilla のコードなのだが、ある世代まではたしかに IOfficeAntiVirus インターフェースにもとづくウィルス検出を行うコードになっている。

ところが、とある世代以降は、IOfficeAntiVirus インターフェースはもう使っていないのだ。

代わりに使われ始めたのは、IAttachmentExecute インターフェースを備えた AttachmentServices という CoClass である。

こいつは、インターネット上からダウンロードしてきたファイルなどを、最終的にファイルシステム上に保存したりするときに利用するらしいのだが、その "保存 (Save)" 処理の一環として、ウィルス検出も行ってくれるのだそうだ。

CodePlex で公開

ということで、それまでの実装はいったん捨てて、AttachmentService & IAttachmentExecute に基づく実装にいちから書き直して、.NET クラスライブラリとして完成させた。

CodePlex で公開してある。

Anti Virus Scanner for .NET (and COM)
http://antivirusscanner.codeplex.com/

いちおう、下記環境で eicar.com の検出と削除が行われることは、自分の手元で確認済みである。
・Win7Pro(x64) 上の Microsoft Security Essentials
・Win7Pro(x86) 上の ESET NOD32 Anti Virus 4

CD や DVD、SD カードや USB フラッシュメモリなどの外部メディアを、大量にスキャンしたいなどの作業の効率化には役立つかもしれない。

　

Mac OS X Lion + Mono で Windows Forms の LT カウントダウンタイマを動かしてみた

先の投稿に書いたとおり、Mac OS X Lion が動作するハードウェアを入手。

実のところ、BootCamp で Windows 7 Pro (x64) での利用が 99% なのだが、しかしお陰で、Mac OS 上での Mono の動作を確認する機会に恵まれた。

Mono とは?

Mono ( モノ ) とは、その筋では言わずと知れた、CLR および .NET Framework のオープンソース実装。

すなわち、あなたの Windows PC 上で作成した、.NET アプリケーション ― .exe ファイル ― が、Mono をインストールした Linux や Mac OS でも動くよ! といった次第である。

※ちなみに Mono は、Windows もサポートしています。

Mono の公式サイトはこちら。
http://www.mono-project.com/

ここから Mono のランタイムをダウンロードして、Mac OS にインストールすることができる。

ライトニングトーク用カウントダウンタイマを試してみた

ということで、Mono でもサポートされている Windows.Forms 上で構築してある、拙作ライトニングトーク用カウントダウンタイマを Mac OS X Lion 上でも動作するかどうか、試してみた。

まずは先に挙げた Mono 公式ホームページ経由で、最新の Mono 2.10.4 をダウンロード。

インストールは難しいことはなく、.dmg パッケージを開いてインストールするだけ。

Mono のインストールが済んだら、次はライトニングトーク用カウントダウンタイマをダウンロードしてくる。

CodePlex のページからダウンロードするのだが、ちょっとしたコツがある。

トップページの「Download」リンクをクリックすると Windows ( っていうか IE ) 向けの ClickOnce 起動用のファイル：.application ファイルが落ちてくるだけなのだ。

別途「Download」タブ、ないしは、トップページの「View all downloads」という小さなリンクをたどって、そこから「Simple Zip version」とかかれた、ただ単に Zip 圧縮しただけの版をダウンロードする必要がある。

リンクはこちら。
http://ltcountdowntimer.codeplex.com/releases

ダウンロードできたら Zip を適当なフォルダに解凍。

あとはターミナルを開いて、解凍したフォルダまでカレントディレクトリを移動し、

$ mono LTCountDownTimer.exe

とするだけである。

例外発生!

ところが大変残念なことに、実行してみたら、例外発生。

System.EntryPointNotFoundException: GdipCreateFromContext_macosx

検索してみたところ、割とメジャーな例外らしい。

ライブラリをビルドし直せとか、X11で強制的に動作するよう環境変数設定しろ、とかあるらしい。

Mac OS の経験が浅く、環境変数の設定方法すら知らなかったので、調べればわかるであろうとはいえ、かなり面倒くさくなった。

そこで別のアプローチ。

上記例外メッセージで検索していたときに見つけた下記スレッド最後のほうの投稿を見て、これに従って試してみた。

https://trac.macports.org/ticket/1936

いったんアンインストール(※)して別のルートから Mono 2.6.7 をインストール。

Mono Tools の Web サイトのダウンロードページから、

http://mono-tools.com/download/

Requires the most recent Mono for Mac OS X

のリンクをたどり、Novell の FTP サイトからダウンロードする。

http://ftp.novell.com/pub/mono/monotools/latest/MonoFramework-x86.dmg

その上で「$ mono LTCountDownTimer」してみたら、とりあえず動きはじめた。

ちょっと感動。

しかしLTカウントダウンタイマは実用に至らず

だけど、下記の弱点があり、残念ながら実用にならなかった。

まず、残念ながら背景透過にならなかった。

次に、ウィンドウ枠が表示されなかった。
その結果、ドラッグしてウィンドウ位置を移動することができなかった。（ただしこれは、ウィンドウ枠をドラッグすることでウィンドウ位置を移動するという、LTカウントダウンタイマーの作りが悪いので、Monoのせいとはいえない）。

さらに、LTカウントダウンタイマーは、時間切れになったらデスクトップを真っ黒なウィンドウで覆うのだが、覆った後のクローズボタン「X」が表示されず、閉じることができなくなった。

幸い、仮想デスクトップを別に開いていたので、そちらからターミナル経由で「$ ps」でmonoのプロセスIDを特定し、「$ kill 」と入力して強制終了することでしのいだ。

とはいえ、いちおう、カウントダウンそのものの動作や表示、スタート／ストップ／リセットの動作は正常だったので、Windows Form の移植状況はあながち悪いものではない（LTカウントダウンタイマーが割と変な作りになっている悪影響のほうが大きい感じ）。

まとめ

残念ながら、ライトニングトーク用カウントダウンタイマは、そのままでは Mac OS X Lion の Mono 2.6.7 上では実用にはならなかった。

とはいえ、実用にならなかった原因はカウントダウンタイマの実装によるものが多い。
カウントダウン動作そのもは至極妥当で、Windows Forms の移植状況はなかなかのものである。

また今回動作が確認できた Mono のバージョンが 2.6.7 であり、最新の 2.10.4 から比べると、マイナーバージョンが 4 つも古い。

もしも例外に対処できて、最新版の Mono で正常動作させることができたなら、もしかしたら背景透過とかも機能するのかもしれない。

※補足：Mono のアンインストール

Mac OS では Windows OS のようなアンインストーラは基本存在しないとのこと。

そこでネット上の情報を頼りに、怖々アンインストールを試みた。

参考にしたのは下記。

http://stackoverflow.com/questions/74902/uninstall-mono-from-mac-os-x-v10-5-leopard

これに従って、.dmg をマウントした上で

$ sudo /Volumes/MonoFramework-MRE-2.xxxx/MonoFramework-MRE-2.xxxxxxx.macos10.novell.x86.pkg/Contents/Resources/uninstallMono.sh

をターミナルから実行。

すると、どうやら Mono のアンインストールに成功した模様だ。
　

Mac で F# & Dozens API Client for .NET

Mac OS X Lion が動作するハードウェアを入手したので、「Mac OS X Lion 上で F# が動作する」ことを自分でも試してみた。

Mac 上で F# を動作させる話は、F# Advent Calendar jp 2010 の優良記事、@sandinist さんの「Mac de F#」など、ネット上にもいくつか見つかる。

CodePlex 上にあるパッケージを使うとか、MacPorts からインストールするなど。

でも自分は、Mono は Mono で評価したかったので、
1. Mono のインストール
2. F# のインストール
と別々の手順でやってみた。

Mono for Mac のダウンロード & インストール

まずは Mono をダウンロードしてきてインストールしておく。

詳しくは後述するが、自分の場合、最新バージョンの 2.10.4 ではなく、2.6.7 をインストールした。

難しいことはなにもなく、ダウンロードした .dmg ファイルを開いてインストール開始するだけ。

F# のダウンロード & インストール

こちらも難しいことはなにもなかった。

Zip をダウンロードして、解凍するだけ。

下記から、「F#, November 2010 Community Technology Preview」の Zip 版(22MB) をダウンロード。

http://www.microsoft.com/download/en/details.aspx?id=18706

どこでもいいから解凍。

解凍できたら、解凍したフォルダ以下の bin フォルダまでカレントフォルダを移動し、

$ mono fsi.exe --gui-

を実行。

見事、F# インタラクティブシェルが起動した。

Dozens API Client for .NET を使ってみる

これだけではおもしろくないので、「Dozens API Client for .NET」を使ってみた。

こちらもダウンロードして適当に解凍。

fsi 起動したら、

「#r "解凍してでてきたDozens.dllへのフルパス";;」

で参照設定成功。

あとは普通に

「open DozensAPI;;」
「let dozens = new Dozens("userId","APIKey");;」

とした上で、

「dozens.GetZones();;」

などなど、普通に操作できた。

まとめ

以上、至極簡単に、Mac OS X Lion 上からでも F# を利用でき、外部のライブラリである Dozen API Client for .NET がすんなり利用できることが確かめられた。

当たり前と言えば当たり前だが、こうして Mac OS の上でも Dozens API Client が動作してしまうのは、改めておもしろい時代だと感慨深い。

補足: 自分の場合の MacOS X Lion への Mono インストール手順

Mono Tools の Web サイトのダウンロードページから、

http://mono-tools.com/download/

Requires the most recent Mono for Mac OS X

のリンクをたどり、Novell の FTP サイトからダウンロードする。

http://ftp.novell.com/pub/mono/monotools/latest/MonoFramework-x86.dmg

あとは、ダウンロードされた .dmg ファイルを開いてインストール開始。
　

広く様々なプラットフォーム・処理系で使われる.NETライブラリを作るには? - #clrh61 LT の資料公開

本日2011年8月27日に TechParty2011 参加型で開催された CLR/H の第61回勉強会。

またしても今回も、懲りずにライトニングトークに登壇させて頂いた。

今回のライトニングトークでは、以前このブログにて報告させて頂いた、国内の DNS サービス Dozens の API クライアントを .NET で作ってみたことを披露した。

以下はそのスライド資料。

実はライトニングトーク当時は、上記のとおり用意したスライドのうち、前半部分しか披露していない。

上記スライドのうち後半、「メイキング・オブ・Dozens API Client for .NET」以降は時間が足りず、ライトニングトーク中には触れることができなかったのだ。

ということで、今回の投稿では、上記LT用スライドの後半について触れておく。

「メイキング・オブ・Dozens API Client for .NET」と題してあるが、これは、実際に Dozens API Client for .NET を作った上で、さらにいろんなプラットフォームに対応させたときに得た、下記の経験・知見を披露するものだ。

広く様々なプラットフォーム・処理系で使われる.NETライブラリを作るには?

詳しくは上記スライドで確認頂きたいのだが、いくつか要点を再録すると以下のとおり。

• PowerShell 2.0 は既定の設定では .NET3.5 の上で動作している。
  .NET4用にビルドされたアセンブリは PowerShell 上にロードできない。
  よって、.NET3.5用としてビルドすること。
• int? など、メソッドの引数に Nullable を使うと、F# からそれを呼び出すときに、ただの "123" とは記述できず、いちいち "Nullable 123" とか書かねばならないので注意。
  これを是とするか非とするか意見は分かれると思う。
  せっかくの F# のシンプルさを損なっている感じがするので、Nullable の使用を避けられるものなら避けたほうがいいかも。

なお、上記スライドでは触れなかったが、C# 4.0 以降で使われているデフォルト引数の機能も、F# では使えない（機能しない）ので留意しておいたほうがいいかも。

場合によっては、デフォルト引数ではなく、複数のオーバーロードバージョンを用意したほうがいいことがあるかもしれない（しかしその場合、後述のとおり COM からの利用で難ありだが）。

さらに、VBScript などなど、COM 経由からの利用も想定に入れるなら、以下の点に注意するとよさげ。

• COM 経由では、引数無しのコンストラクタでしかオブジェクト生成できない。
  必ず引数無しコンストラクタも用意すること。
• COM 経由では、メソッドのオーバーロードとあまり相性良くない。
  呼び出せないわけではないが、 "MyMethod"、"MyMethod_2"、"MyMethod_3"... というように、連番のサフィックスがランタイムによって自動で付加される。

以上、どうぞご参考まで。