0

I making an application that builds report in LibreOffice Calc using LO SDK libraries from 3.6 version. These dlls are .NET 2.0, afaik, and my application is .NET 3.5, so it works fine together.

But when I run application on an PC where LO 4.0 is installed, it looks like it trying to load dlls not from application folder (where correct dlls are copied), but from somewhere in host PC, as it throws exception "This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded" on load cli_uno.dll (when I try to run a report). Looks like LO 4 SDK dlls are assembled for .NET 4.0?

Well, it's not an option to rebuild application for .NET 4.0 (as it will repeat when there'll be any new .NET 5.0 dlls).

Is there any way to make application load dlls from its own folder only?

UDPATE That cli_uno.dll actually isn't included in my application at all. It is in LO installation folder and obviously called by those 'cli_*.dll' files, that I included in my application. But I can't control what version of LO will be installed! It just out of control by any assemly version settings. It just not right when application working fine with LO 3.6, but stop working after upgrade to LO 4.0. Seriously, I've made applications in ancient Delphi 7 using ancient libraries to connect to MS Excel (that was created when XP/2000 versions were actual) and it works fine with at least 2007 version.

Isn't it supposed to use interfaces, for applications of different versions, even different platforms, was able to interoperate, exchange data between them? May be I'm using LO SDK completely wrong?

yaapelsinko
  • 639
  • 1
  • 10
  • 18
  • Possible duplicate? http://stackoverflow.com/questions/267693/how-can-i-force-net-to-use-a-local-copy-of-an-assembly-thats-in-the-gac – Nicole DesRosiers Jul 31 '13 at 00:41
  • As I see now, it's not in control of application assembly version settings - that 'cli_uno.dll' is not a part of my application, but LO installation, and it called by my app. I've updatew the question. – yaapelsinko Aug 02 '13 at 00:21

1 Answers1

0

Is your local assembly signed? If you can remove the signing on the dll contained in your folder, then it always loads from that folder. As long it is signed, it first looks into the GAC.

Prash
  • 1,122
  • 1
  • 8
  • 10
  • Actually, none of my application assembly components are signed. But LO SDK's dll must be signed. Doubt I can remove the sign from it. – yaapelsinko Jul 31 '13 at 01:07
  • Obviously you cannot.But may be you can use Assembly.Load() during your application starts, thus loading the dlls required by you into Memory, rather than waiting for the framework to scan for the dlls. Not quite sure though. – Prash Jul 31 '13 at 01:11
  • As I see now, it's not in control of application assembly version settings - that 'cli_uno.dll' is not a part of my application, but LO installation, and it called by my app. I've updatew the question. – yaapelsinko Aug 02 '13 at 00:21