MicrosoftがVisualStudioを「進化」させるほど、プロセス全体が無知になることを誓います。
3つのクラスライブラリを含むWindowsサービスがあります。各クラスライブラリのプロパティに移動し、プラットフォームターゲットをx64に設定しました。すべてを検証するために追加したテストコンソールプロジェクトだけでなく、Windowsサービスにも同じことを行いました。
Windows 2008 R2 x64サーバーでコンソールアプリケーションを問題なく実行できますが、愚かなインストーラーが爆撃を続け、イメージが悪いと言ってきます。インストーラーのターゲットプラットフォームをx64に設定したことを確認しました。
このばかげたことが爆撃されて、どんな洞察も本当に感謝するだろうかと私は知りません。私は他のDLLを参照していますが、それらはx86である可能性がありますが、メインライブラリが適切に設定されていれば、うまくいくと思いました...
私はついにこれを理解しました-それはアーキテクチャ、参照、または他のナンセンスとは何の関係もなく、インストーラー自体と関係があります。 この記事で説明しているように、Visual Studioインストーラーはデフォルトで32ビットDLLを使用し、それが失敗の原因です。
この問題を解決するには、次の手順に従ってください。
つまり、MSIファイルをOrcaに保存してから展開します。x64のインストールは、それ以上問題なく機能するはずです。
Visual Studio 2017で、この問題に遭遇しました。長い間x86であったアプリケーションのx64バージョンのインストーラーを構築していました。
ケンの答えが決定的なものであることは間違いありませんが、カスタムアクションはインストールされたアプリケーションではなくインストーラーによって呼び出されるため、少なくとも私の場合は、カスタムを含むプロジェクトは必要ないことに気付きました。そのクラスはアプリケーション自体によってインスタンス化されることはないため、アプリケーションの他の部分と同じビット数を持つアクション。
そこで、そのプロジェクトのプラットフォームだけをx86に戻し、インストーラーを再構築しました。
それはすべて「うまくいった」。
もちろん、これは、ソリューションの他の部分から完全に分離されたカスタムアクションがあるかどうかに依存します。ただし、Orcaを使用する必要がないので非常に安心です。
このエラーは、64ビットマシンに.Net4.5+サービスをインストールするときに発生しました。
BadImageFormatExceptionでインストールが失敗します。
私にとっての解決策は、サービスプロジェクトのプロパティに移動し、ビルドプラットフォームを[任意のCPU ]に変更し、デフォルトでオンになっている[ 32ビットを優先する]チェックボックスをオフにすることでした（意味も参照してください）。