.NET 用 Excel ファイル読み書きライブラリ「ClosedXML」を .NET Core 上で使う - 2017年12月21日時点の、ちょっと強引な対応方法

ClosedXML とその .NET Core 対応状況

C# などの .NET 環境において、Excel ファイルを読み書きするライブラリとしては、自分が知っている範疇では以下を挙げられる。

• ClosedXML
• EPPlus
• NPOI

このうち、自分は ClosedXML をよく使っている。

ところが残念なことに、2017年12月21日現在は、ClosedXML はまだ .NET Core に正式対応していない。

.NET Core 2.0 のプロジェクトに、ClosedXML の NuGet パッケージをインストールすることはできる（ただし、依存している NuGet パッケージが解決できないため、さらに手作業で DocumentFormat.OpenXml と FastMember.Signed の 2 つの NuGet パッケージを明示的にプロジェクトに追加する必要がある）。

しかしそのプログラムを実行して、実際に何か Excel ファイルを読み込む処理を実行すると、
「Could not load type 'System.Drawing.ColorTranslator' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'」
という実行時例外が発生してしまう。
.NET Core 2.0 ランタイム上では、System.Drawing.ColorTranslator クラスは実装されていないためだ。

ということで、2017年12月21日現在時点では、残念ながら .NET Core 上では ClosedXML は使えないということとなっている。

なお、ClosedXML に代わって、.NET Core 上でも利用可能な Excel ファイル読み書きライブラリとしては、EPPlus のベータ版があるようだ。

しかしながら自分はこれまで EPPlus を使ったこともなく、今から EPPlus に乗り換えるのもちょっと億劫に感じていた。

ClosedXML も .NET Core 上での利用に向けて対応が進行中

ところで、ClosedXML の .NET Core というか .NET Standard 2.0 対応は、実は Issue も立てられてて、別途進行中ではある模様だ。

そこで、この進行中のコードを持ってきて、私家版の ClosedXML NuGet パッケージを生成すれば、自分の .NET Core プロジェクトでも ClosedXML が使えるようになる。

ということで実際にやってみたので、その手順を以下に記す。

.NET Core 対応 私家版 ClosedXML パッケージのビルド手順

自分の環境は Windows OS。
用意するものは git と Visual Studio 2017 だ。

自分は Visual Studio の Pro Edition でこの作業を行ったが、条件を満たせば無償で利用可能な Visual Studio Community Edition でも大丈夫ではないかと思う。
また、本質的には Visual Studio は必須ではなく、.NET Core 2.0 の SDK さえあれば、dotnet コマンドで、以下で説明しているのと同じことを実行可能なはず（そしておそらくは macOS などでも）、と考えている。

さておき、ClosedXML の .NET Standard 2.0 対応は、本家の ClosedXML GitHub リポジトリから fork した、igitur 氏の GitHub リポジトリで進行している模様だ。

そこで、この igitur 氏 fork 版の GitHub リポジトリをローカル環境に git clone する。> git clone git@github.com:igitur/ClosedXML.git
> cd ClosedXMLそして、.NET Standard 2.0 対応は、netstandard2 ブランチで進行している様子。
なので、netstandard2 ブランチをチェックアウトする。> git checkout netstandard2次に、ソリューションファイル ClosedXML.sln を Visual Studio 2017 で開く。

Visual Studio でソリューションを開いたら、ソリューションのコンフィギュレーションを Release に選択変更し、ソリューションエクスプローラ上でプロジェクト「ClosedXML」を右クリックして「パッケージ」をクリックする。すると、ひととおりビルドが始まって、最終的に ./ClosedXML/bin/Release フォルダに ClosedXML.0.9.0.nupkg ができあがる。

パッケージ ID の変更

基本的には、こうしてできた NuGet パッケージを使えば OK だ。

ただ、本家・公式のものと、パッケージ ID もバージョンも同じだが、中身が違う NuGet パッケージとして、この "ClosedXML.0.9.0.nupkg" をプロジェクトに取り込むと後々面倒なことになる。

そこで、どうせ私家版ビルドなので、パッケージ ID を変えてしまおう。

Visual Studio のソリューションエクスプローラ上からプロジェクト「ClosedXML」を右クリックしてプロパティを選択し、出てきたプロジェクトのプロパティの画面中、「パッケージ」のカテゴリを開くと、そこにパッケージ IDなどを設定する画面となる。

ここでパッケージ ID やバージョンなどを、適宜、私家版ビルドにふさわしいものに改変する。その上でもういちど、プロジェクト「ClosedXML」の右クリックからのパッケージ再実行で、改変後のパッケージ ID で NuGet パッケージファイル (.nupkg) ができあがる。

取り扱い上の注意

この改変後の私家版 ClosedXML パッケージだが、さすがに nuget.org に公開するのはまずいであろう。

なので、ローカルディスクであったり、あるいは会社内の LAN 上の共有フォルダに置いておくか、はたまた Visual Studio Team Service で使えるプライベート NuGet リポジトリに収録するなどして、プライベート用途に限定して非公開で配備するのがよかろうかと思う。

あと、言わずもがなだが、いくら GitHub 上で公開されているとはいえ、この私家版ビルド対象のコミットは、まだ .NET Standard 2.0 対応の仕掛中のものだ。

コミッタの igitur 氏も、私家版ビルドとはいえ、この netstandard2 ブランチからパッケージ作成して利用されることは想定していないことと思う。

まだ作業中であるが故の、igitur 氏本人にとっては既知の、これから取り掛かろうとしていた不具合修正などが多々残されてるかもしれないことは想像に難くない。
このあたりの背景や状況をよく踏まえた上で、利用可否の判断をすべきと思われる。

また、折角の機会なので、ClosedXML の .NET Standard 2.0 対応にあたり、何か助力できることがあれば、フィードバックするに越したことはないだろう。