ここまで、Excel-DNA のいくつかの機能を利用してユーザー定義関数（UDFs：User Defined Functionｓ）の作成方法を紹介してきました。まだ利用していない機能も多いのですが、ちょっと立ち止まって、作者の意見 を参考にしながら、Excel カスタマイズにおける Excel-DNA の利点について考えてみたいと思います。
（初めての方は、本家⇒Excel-DNA(CodeProject) 、使い方⇒Excel-DNAでXLLをつくる（その１）を参照してください）
MSDNを調べてみる：
そもそも、Excel のカスタマイズにはどんな選択肢があるかというと、1.VBA 2.VSTO 3.XLL 4.FluentUI 5.Excelサービス 6.Open XML があり（参照：「Excel デベロッパー センター」）、加えて UDFｓ には 7.オートメーションCOM という選択肢があります。（参照：「Excel から使うマネージDLL を作る」）
これらの方法それぞれの目的は何でしょうか？ 4～6 が、インターフェースの拡張を目的とするのは明らかですが、1.VBA 2.VSTO 3.XLL はどのような棲み分けになっているのでしょう？
「VBA を使用する状況と理由」 をみると、その目的は主にインターフェースの開発にあることがわかります。
「Excel 2010 のパフォーマンス」 の中では、
通常、Excel の数式計算とワークシート関数を使用した方が、VBAユーザー定義関数を使用するよりも高速です。（VBA)ユーザー定義関数は呼び出すたびに小さなオーバーヘッドが発生し、さらに、Excel からユーザー定義関数に情報を転送するときには大きなオーバーヘッドが発生します。
と VBA UDFｓ のオーバーヘッドに言及し、VBA UDFｓ の積極的な使用には否定的です。
VSTO はというと・・・正式には UDFｓ をサポートしていません。（不可能ではないようです⇒How to create UDFs…）
一方、 XLL はロジックの開発を目的としていることが 「Excel 2010 での変更点」 から読みとれると思います。
- 2010 で導入された、「高性能コンピューティング (HPC)」を利用するにはユーザー定義関数を XLL で実装する必要があり、VBA やCOM オートメーション アドインでは、クラスター セーフなユーザー定義関数を作成できません。
- 「非同期ユーザー定義関数」も XLL で定義する必要があります。
- Excel2007 から ワークシート関数がマルチスレッド対応になっていますが、マルチスレッド対応の UDFs を作成できるのは XLL だけで、VBA・COM・XLM ではマルチスレッド計算を行うことはできません。
Excel自体が、C API （2007 から Excel12v ）なので、当然かもしれませんが、核となるロジックに関するインターフェースのバージョンアップは XLL を対象として行われています。
Microsoft は「ロジックはネイティブな XLL で開発し、インターフェースはVBA やCOMで開発する」 ことを、意図しているように感じますし、上にあげた記事を見るとそのようにサポートされています。
Excel-DNAの立ち位置：
以上の理由から、ユーザー定義関数（UDFs）は、C API （XLL） で開発するのが王道であると言えます。
しかしながら、SDKによる XLL開発はVBA ユーザーにとっては少々敷居が高く、マネージコードに馴れている者にとっては、豊富なマネージクラスが利用できないストレスもあります。
さて、このようにロジック開発という観点から見ると・・・
高速なXLLアドイン をマネージコードで効率良く開発できる Excel-DNA はとてもありがたいツールなのです。Excel-DNA の作者 Govert によると、XLL によるマネージコードの呼び出しオーバーヘッドは100プロセッサ命令以下であり、マルチコアプロセッサ環境ならマルチスレッド処理によって更に高速化するとのことです♪
（Excel-DNA で XLL をつくる（その６）では、同じ処理でVBA と処理時間を比較してますので参照して下さい）
では、インターフェース開発ではどうでしょう・・・
Excel-DNA は リボンカスタマイズ機能を有していますし、最新版（ver0.29）では CustomTaskPane や COMServer もサポートされ、インターフェース開発機能も充実してきており、応用範囲が広くなっています。
（きぬあさ氏の「ユーザーインタフェースとプログラムコードの分離」でリボンカスタマイズが解説されています）
大事なことを忘れてました・・・(笑)
なぜExcel-DNA なのか？ もうひとつの利点は、配布が簡単なことかもしれません。.dna 、.xll ２つのファイルを配布するだけで、インストールの必要が無いのですから！ XLLファイルを Excel へドラグ＆ドロップして、一度限り動作させるもよし。アドイン登録して継続的に利用するもよし。
まとめ：
- C#、F#、VB.NET といったマネージ言語で開発でき、．NetFramework の豊富なクラスが使える
- Excel の核と同じネイティブ C API であり、呼び出しのオーバーヘッドがきわめて小さく高速
- HPC や マルチスレッドといった XLL ならではの最新機能を利用することができる
- リボンやカスタムタスクペインなどの新しいユーザーインターフェース開発機能をもつ
- 配布はファイル２つだけでインストール不要である
といったところでしょうか。
自分はVBA も（たまに）利用しますし、XLL の作成にはSDK も（たまに）利用します。VSTO は良く分からないんですが・・・（汗。あまり処理速度を気にしないなら、ちょっとしたロジックをVBAやVSTOで記述しても良いでしょうし、大きなクラスをマネージDLL化してVBAから利用する方法は結構お気に入りだったりします。 XLL開発にしても、XLW のようにマネージコードを利用できるツールは他にもありますので、状況に応じて使い分けるのが良いでしょう。
しかし・・・マネージコードによるXLL開発の簡便さにおいて Excel-DNA の右に出るものはなく、Excel カスタマイズツールとして、はずせないツールだと思います。
一度、お試しください。
次回は、関数の揮発性を制御してみたいと思います。
では、また(笑)
Pingback: Excel-DNA | FILES=0