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

# はじめに
これは、[C# Advent Calendar 2020](https://qiita.com/advent-calendar/2020/csharplang)の11日目の記事になります。

予定では漢数字のソートなどについての記事にしようと思ってたのですが、検証用プログラムが間に合わなかったため別の機会とします。「[その2](https://qiita.com/advent-calendar/2020/csharplang2)」はまだ空き日があるようですし。

最近の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移行について](https://qiita.com/yaju/items/7cf5ab6987ecd1d83b13)

ユーザーに提供しているアプリケーションの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」について](https://qiita.com/yaju/items/86314412741deb806366)

プロバイダー部分を「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 が利用できない](https://social.msdn.microsoft.com/Forums/ja-JP/37cfef18-f40e-4453-b18f-43adb040c0cd/-office-office-office-oledbodbc-?forum=officesupportteamja)

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のレポートが使えるのだろうか？

```csharp: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();
```

```vb: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に変更するには](https://qiita.com/mindwood/items/039d4a192b6906c562f6)

その結果、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環境によるテスト漏れがあったことは否めません。今度は気をつけましょう。