3.6 バージョンの LO SDK ライブラリを使用して、LibreOffice Calc でレポートを作成するアプリケーションを作成しています。これらの dll は .NET 2.0 であり、私のアプリケーションは .NET 3.5 であるため、一緒に問題なく動作します。
しかし、LO 4.0 がインストールされている PC でアプリケーションを実行すると、アプリケーション フォルダー (正しい dll がコピーされる場所) からではなく、ホスト PC のどこかから dll をロードしようとしているように見えます。現在ロードされているランタイムよりも新しいランタイムであり、読み込めません" on load cli_uno.dll (レポートを実行しようとしたとき)。LO 4 SDK dll が .NET 4.0 用にアセンブルされているように見えますか?
まあ、.NET 4.0 用にアプリケーションを再構築するオプションではありません (新しい .NET 5.0 dll があると繰り返されるため)。
アプリケーションに独自のフォルダからのみ dll をロードさせる方法はありますか?
UDPATEその cli_uno.dll は、実際には私のアプリケーションにはまったく含まれていません。これは LO インストール フォルダーにあり、アプリケーションに含めた「cli_*.dll」ファイルによって明らかに呼び出されます。しかし、インストールされる LO のバージョンを制御することはできません。アセンブリのバージョン設定では制御できません。アプリケーションが LO 3.6 で正常に動作している場合は正しくありませんが、LO 4.0 にアップグレードすると動作しなくなります。真剣に、私は古代のライブラリを使用して古代の Delphi 7 でアプリケーションを作成し、MS Excel (XP/2000 バージョンが実際に作成されたときに作成されました) に接続しましたが、少なくとも 2007 バージョンで正常に動作します。
異なるバージョン、異なるプラットフォームのアプリケーションが相互運用し、それらの間でデータを交換できるようにするために、インターフェイスを使用することになっているのではないでしょうか? LO SDKを完全に間違って使用している可能性がありますか?