これは厳密にはあなたの質問に対する回答ではないことは承知していますが、懸賞金を設定した後もまだ回答が得られていないため、とにかく提案できると思いました...
アプリケーションの 64 ビット バージョンが本当に必要かどうかを再検討することもできます。ほとんどの基幹業務アプリケーション (そこからレポートを生成しているので、構築しているものと推測できます) は、64 ビットであることから実際にはメリットがありません。
ビルドして配布できるのは 32 ビット バージョン (x86) のみであり、32 ビット バージョンまたは 64 ビット バージョンの Windows を実行しているかどうかに関係なく、すべてのマシンで引き続き実行されます。これは、すべての 64 ビット バージョンの Windows に、32 ビット コードを実行する特別なサブシステム ( Windows-on-Windows または WOW64 ) が含まれているためです。それは完全にシームレスで、言うべき互換性の問題は事実上ありません。
多くのアプリケーションがこの方法でデプロイされています。Visual Studio 自体はその好例です。これはまだ 32 ビット コードですが、WOW64 のおかげで 64 ビット バージョンの Windows でも問題なく動作します。
これを行うには、x86 プラットフォームを対象とするようにプロジェクトを設定し、32 ビット DLL のみを参照するだけです。ビルドするバイナリは 1 つだけなので、参照する DLL を特定するだけでなく、テストする必要があるコードの量と配布プロセス自体の点でも、開発と配布の作業が大幅に簡素化されます。
標準的なイディオムと推奨されるプラクティスに従う優れたコードを作成した場合、後で 64 ビット サポートを追加することは (それがあなたのケースに何らかの利益をもたらすことが判明した場合)、かなり簡単な操作になります。.NET Framework は、プラットフォーム固有の違いを非常にうまく抽象化します。それが、「任意の CPU」ターゲット オプションを提供できる方法です。
それはさておき、(Crystal Reports について特別な経験がないので) 推測を許すならば、パブリック インターフェイスは 32 ビット DLL と 64 ビット DLL の両方で同一であると思います。
その場合、開発作業用に 32 ビット バージョンを参照するだけで、ビルド スクリプトを構成して、32 ビット バイナリと 64 ビット バイナリのどちらをビルドしているかに応じて、DLL の正しいバージョンを選択できます。
当然、インストーラーは、インストール中 (統合インストーラーを使用している場合) またはインストーラー自体をビルドするとき (32 ビットと 64 ビットのインストーラーが別々にある場合) に、同じ選択を行う必要があります。