筆者について
私は普段、主に金融業界向けの受託開発のアーキテクトを務めています。特に所属会社の特性上、電子と紙をまたがった領域を得意としています。
本稿はエンタープライズ領域でのアプリケーション開発者の視点で記載しています。したがって立場が変わればその見方は大きく変わるでしょう。しかし、異なる立場の方であっても、ExcelやPDFを扱う上で検討するに値する素晴らしい製品のはずです。ぜひ本稿を一読いただければと思います。
なお、本稿で扱ったコードはすべてGitHubに公開しています。部分的なコードで分かりにくい部分は併せてこちらもご覧ください。
DioDocsの魅力【1】
DioDocs for ExcelとDioDocs for PDFは、.NET向けのExcelファイルおよびPDFを操作するためのライブラリです。
具体的にサポートする機能については、それぞれのサイトを見てください。
私は先ほど、DioDocsに衝撃的な魅力を感じたと書きました。その魅力は、単に機能がどうのという話ではありません。多数の選定要因が非常にバランスよくまとまっている点にあると考えています。
これまでも.NETからExcelやPDFを操作する方法は多数存在しました。例えばExcelファイルを操作する方法を簡単に挙げてみると、次のような手段があります。
Microsoft.Office.Interop.Excel
Microsoft純正のExcelのCOMによるオートメーションライブラリ。
Visual Studio Tools for Office（VSTO）
Microsoft純正のExcelなどのOfficeアドイン作成用フレームワーク。
Open XML
Microsoftが主導して開発する、OSSのOfficeファイル操作用API。Excel以外にも対応しているが煩雑。
ClosedXML
Open XMLをラップしExcel準拠のオブジェクトモデルに寄せたExcelファイル操作ライブラリ。
NPOI
Java製のApache POIを.NETに移植したライブラリ。APIの独自性が高い。
EPPlus
xlsファイルもサポートしたライブラリ。比較的Excelのオブジェクトモデルに近い。
これらはすべて無償で利用でき、なおかつ実績のあるプロダクトです。
対してPDFは「主要なライブラリ」を挙げることも実は悩みます。例えばOSSのPDF製品を考えてみましょう。OSS系のPDFライブラリとなると、最近はiTextやPDFSharpをよく見かけます。
しかし後ほど詳細に説明しますが、PDFSharpはクライアントプロセスでの利用であれば問題ありませんがサーバープロセスでの利用は危険です。対してiTextはデュアルライセンスで、無償利用可能なライセンスはAGPLであることから利用シーンが限られますし、有償版は非常に高価です。
ではその他の商用製品はどうかと言いますと、実は多数存在します。しかし機能一覧だけ眺めていても決定的に優位な要素は見えてきません。
このようにExcelとPDFを取り囲むライブラリの環境はそれぞれ全く異なります。そういった状況の中で私が衝撃を受けた理由は、DioDocsの細かな機能の一覧にあったわけではありません。次のような複数の選定要因が、非常にバランスよく成り立っていることが大きな要因です。
- ExcelファイルからPDFファイルの生成
- .NET Standard 2.0準拠
- ランタイムフリー
- Excel準拠のオブジェクトモデル
- 開発元は日本が本社の企業なので直接サポートが受けられる
これらの非常に絶妙なバランスが、衝撃的ともいえる魅力を生み出しています。そして実際に評価目的で利用して、次のもう1つの魅力に驚かされました。
- 軽快な動作速度
何がそこまで魅力的なのか？ 端的に言えば「クラウド時代のユーザーメンテナンス可能な帳票生成サービスの構築に最適である」ということです。なぜそうなのか、順番に説明していきましょう。
ExcelファイルからPDFファイルの生成
これまでも前述のOpen XML、ClosedXML、NPOI、EPPlusといったExcelファイル操作ライブラリを利用して、Excelをテンプレートとして帳票出力することは可能ではありました。しかしその場合、出力形式は必然的にExcelに限られました。
Excel形式のまま帳票として運用することもケースによっては可能でしょう。しかしExcelのままでは容易に編集が可能であることが、業務帳票として扱うには不適切なケースも多いはずです。
しかしDioDocs for ExcelはPDFを生成することができます。
Excelを帳票のテンプレートとして登録しておき、必要な値を設定した上でPDF化することで、容易にメンテナンス可能な帳票生成サービスを構築することができます。そこにDioDocs for PDFを併せて利用することで、デジタル署名を用いて改ざんを抑止することも可能になります。
先に挙げたExcel関連ライブラリの中でも、次の2つはExcelからPDFへ直接変換できます。
- Microsoft.Office.Interop.Excel
- Visual Studio Tools for Office（VSTO）
しかし、これらはいずれもサーバーサイドでの利用は不適切です。
1．はMicrosoftから明確に非推奨とされています。
Microsoft Officeがインストールされている必要があることから、ライセンスからして不明確です（明確に可もしくは不可と書かれた文書の存在を知りません）し、単純に技術的な側面だけ見てもリスクが高すぎます。実際に非推奨であることを知らずに利用して、トラブルとなったプロジェクトが数多く存在します。特に次の点に大きな問題があります。
- COMオブジェクトのリソース開放漏れが起こりやすく、ゾンビExcelプロセスが発生しやすい
- 動作が非常に遅い
- マルチスレッド非対応
- 何らかのユーザーダイアログが起動した場合、処理がすべて停止する
- 動的にアセンブリをロードしない場合、Excelのバージョンに依存する
- 動的にアセンブリをロードすると、型安全性が失われる
また2．のVSTOはOfficeのAddInを作成するための仕組みであり、サーバーサイド オートメーションには利用できません。
その2つ以外のライブラリはサーバーサイドでの処理にも利用できますが、ExcelからPDFを生成することが可能なのはDioDocs for Excelのみです。
.NET Standard 2.0準拠
Microsoft.Office.Interop.ExcelとVSTO以外は.NET Standard 2.0に準拠しています。これは.NET Framework、.NET Core、Mono（つまりXamarinなど）といった、複数のプラットフォームの.NETランタイム上で動作が可能だということです。
特に.NET Core上で動作するということは、クラウドやDockerコンテナ上で利用しやすく、マイクロサービスやサーバレスアーキテクチャとも相性が良いというメリットがあります。
また.NET Standardに準拠しているということはSystem.Drawing.BitmapやSystem.Drawing.Graphics、つまりGDI+に依存していないことを意味します。サーバーサイドで画像操作をする場合、System.Drawingパッケージの利用は未サポートです。
サーバーサイドでの画像操作にはWindows Imaging Componentが推奨されていますが、これの標準の実装クラスはPresentationCoreというWPFのアセンブリに含まれており、実はそのアセンブリが同様にサーバーサイドでの利用がサポートされていません（C++のネイティブライブラリを自力でラップすることは可能でしょう）。
System.Drawing系のクラスをサーバーサイドで動かしても一見正しく動作します。しかし、まれに落ちます。私の経験上、月間数十万枚の画像を処理して年に1回落ちるかどうか？ 程度ですが、落ちるときには例外も発生せず、プロセスが無言で停止します。Windowsのイベントログを見ると、Bitmapクラスのコンストラクタを呼んだだけでプロセスが落ちたように見えました。
このようにSystem.Drawingパッケージは.NETで画像操作をする手軽な手段を提供してくれていますが、実のところサーバーサイドでの画像操作となると一筋縄ではいきません。特にPDFでは画像を扱う頻度が高いと考えています。
DioDocsはいずれも.NET Standard準拠で、その辺りの実装はSystem.Drawingに依存しない独自実装になっており、サーバーサイドでの動作もサポートしています。これは非常に重要なポイントだと考えます。
