【.NET】32bitアプリ(x86)からOffice 64bitのアプリケーションの操作は出来るのか

はじめに

これは、C# Advent Calendar 2020の11日目の記事になります。

予定では漢数字のソートなどについての記事にしようと思ってたのですが、検証用プログラムが間に合わなかったため別の機会とします。「その2」はまだ空き日があるようですし。

最近のPCは64bitであり、Windows OS側も64bitとなっているのが一般的になりました。
Officeのアプリケーションを操作するのに、Microsoft.Office.Interop.XXXXX を参照したとして、次の環境で動作するの？ というのが今回の記事になります。

プラットフォーム ターゲット	Office ビット	動作
AnyCPU(64bit)	Office 64bit	問題なし
AnyCPU(64bit)	Office 32bit	?
x86	Office 32bit	問題なし
x86	Office 64bit	?

64bit版WindowsのJet.OLEDB.4.0問題

2018年からサーバーリプレース作業でデータベースを Oracle 11g から PostgreSQL 9.6 に移行しました。
OracleからPostgreSQL移行について

ユーザーに提供しているアプリケーションの1つにC#のアプリケーション(2011年頃に作られたもの)があり、印刷機能は2種類で1つはCrystalReport(Visual Studio 2008のバンドル版)を使用したもの、もう1つはAccessのレポート(mdb)を使用していました。
Accessのレポートは、ユーザー側でレポートのデザインを変更できるということで採用されているようです。

レポート用のデータをmdbファイルに登録する必要があるのですが、64bit版Windowsでは「Microsoft.Jet.OLEDB.4.0」が提供されていません。
AnyCPU（64bit）でmdbを操作しようとすると「'Microsoft.Jet.OLEDB.4.0' プロバイダはローカルのコンピュータに登録されていません。」というエラーになります。
64bit版Windowsでの「Microsoft.Jet.OLEDB.4.0」について

プロバイダー部分を「Provider=Microsoft.Jet.OLEDB.4.0」 → 「Provider=Microsoft.ACE.OLEDB.12.0」に書き換えるといいのですが、この場合には「Microsoft Access データベース エンジン 2010 再頒布可能コンポーネント」のインストールが必要になります。
昨今のOffice 365でも、Microsoft Access は標準でインストールされるのですが、クイック実行形式の Office 製品をインストールした場合、OLEDB プロバイダーは登録されないのです。
クイック実行形式の Office をインストールすると Office 以外のアプリケーションから ODBC / OLEDB が利用できない

ClickOnceアプリケーションということもあって、別途「Microsoft Access データベース エンジン 2010 再頒布可能コンポーネント」のインストールさせるのも、なんだしなということもあり別案で行くことにしました。
64bit版Windowsには32bitプログラムを動かす仕組み「WOW64」がありますので、その環境内でなら「Microsoft.Jet.OLEDB.4.0」が使用することができます。そのためプラットフォームターゲットをAnyCPUからx86にを変更しました。
プラットフォームターゲット変更のデメリットとして、前バージョンのアプリケーション設定を引き継ぐことが出来なくなります。ここはユーザー側で最初から入力し直してもらう手筈になりました。

テスト作業も終えて、ユーザー側にも導入しました。

Office 64bit

1年以上経ってからユーザー側から、印刷しようとしたらエラーになるとの報告がありました。
どうも新しいPCに導入したようです、Windows 10 64bit ＋ Office 365 64bit の環境となっているとのこと。

エラーのログはまだもらっていなかったのですが、Office 64bitの環境でテストしていなかったことに気が付いたのです。
会社から提供されているPCは Office 32bit版であり、開発やテストでもその環境でやっていたためです。

はたして、32bitアプリケーションから64bit版のAccessのレポートが使えるのだろうか？

C#

using Access = Microsoft.Office.Interop.Access;

Microsoft.Office.Interop.Access.ApplicationClass oAccess = null;

//レポートの印刷
oAccess = new Microsoft.Office.Interop.Access.ApplicationClass();
oAccess.OpenCurrentDatabase(MDBFileName, false)
oAccess.DoCmd.OpenReport(REPORT_NAME, Access.AcView.acViewNormal, null, null);
oAccess.CloseCurrentDatabase();

VisualBasic

Imports Access = Microsoft.Office.Interop.Access

Dim oAccess As Microsoft.Office.Interop.Access.ApplicationClass = Nothing

'レポートの印刷
oAccess = New Microsoft.Office.Interop.Access.ApplicationClass()
oAccess.OpenCurrentDatabase(MDBFileName, False)
oAccess.DoCmd.OpenReport(REPORT_NAME, Access.AcView.acViewNormal, Nothing, Nothing)
oAccess.CloseCurrentDatabase()

今のところテスト環境はOffice 32bit版しかありません。
64bit環境からOffice 32bitの呼び出しが出来れば、その逆の32bit環境からOffice 64bitでも大丈夫ではないかと推測です。
テスト的にアプリケーションのプラットフォームターゲットをAnyCPUに変更、プロバイダー部分を「Provider=Microsoft.Jet.OLEDB.4.0」 → 「Provider=Microsoft.ACE.OLEDB.12.0」にして、「Microsoft Access データベース エンジン 2010 再頒布可能コンポーネント」の64bit版をインストールして動かしてみました。

その結果、Accessのレポートが印刷できました。

その後、別途テスト環境用のPCを用意してもらい Office 365の32bitから64bitに入れ直しました。Office 365なら比較的簡単に変更が出来ました。
永続ライセンス版Officeを32bitから64bitに変更するには

その結果、32bitアプリ(x86)からでもAccessのレポートが印刷できました。

ユーザーからログをもらうと、Microsoft Accessがインストールされていたないためにエラーが発生していました。

System.Runtime.InteropServices.COMException (0x80040154): CLSID {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9} を含むコンポーネントの COM クラス ファクトリを取得中に、次のエラーが発生しました: 80040154

結論

プラットフォーム ターゲット	Office ビット	動作
AnyCPU(64bit)	Office 64bit	問題なし
AnyCPU(64bit)	Office 32bit	問題なし
x86	Office 32bit	問題なし
x86	Office 64bit	問題なし

最後に

最初は焦りましたがプログラムの修正はしないで済みました。
Excel操作だったら、オープンソースのNPOIやEEPlusやClosedXMLなどに変更すればいいですが、Accessだったのでどうしようもないです。

なんにしても、office 64bit環境によるテスト漏れがあったことは否めません。今度は気をつけましょう。