System.InvalidCastException was caught Message=Unable to cast object of type 'System.IntPtr' to type 'System.Runtime.InteropServices.GCHandle'. Source=cli_cppuhelper StackTrace: at uno.util.to_cli<class com::sun::star::uno::XComponentContext>(Reference<com::sun::star::uno::XComponentContext>* x) at uno.util.Bootstrap.bootstrap() at Libre4.SpreadsheetDocHelper.connect(String[] args)
I got very similar exception: System.InvalidCastException was caught HResult=-2147467262 Message=Unable to cast object of type 'System.IntPtr' to type 'System.Runtime.InteropServices.GCHandle'. Source=cli_cppuhelper StackTrace: at uno.util.to_cli<class com::sun::star::uno::XComponentContext>(Reference<com::sun::star::uno::XComponentContext>* x) at uno.util.Bootstrap.defaultBootstrap_InitialComponentContext(String ini_file, IDictionaryEnumerator bootstrap_parameters) at uno.util.Bootstrap.defaultBootstrap_InitialComponentContext() when calling: XComponentContext xLocalContext = uno.util.Bootstrap.defaultBootstrap_InitialComponentContext();
Tested 4.0.1.2 and 4.0.0-beta1 and both throws this errors. In version 3.5.6 there is no such error and everything works just fine.
Can confirm this error with LO 4.0.0.3 and LO 4.0.0.3 SDK Seems to be related to going to .NET 4.0
LibreOffice Verze 4.0.1.2 (ID sestavení: 84102822e3d61eb989ddd325abf1ac077904985) funct Bootstrap.bootstrap() ERRORR!!! Could not load file or assembly 'cli_cppuhelper, Version=1.0.22.0, Culture=neutral, PublicKeyToken=ce2cb7e279207b9e' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ERROR!!! VS2010 Express, Active debug x86 app.config ---------- <startup useLegacyV2RuntimeActivationPolicy="true"> <requiredRuntime version="v4.0.20506"/> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/> </startup>
same exception : uno.util.Bootstrap.bootstrap() Impossibile caricare il file o l'assembly 'cli_basetypes, Version=1.0.19.0, Culture=neutral, PublicKeyToken=ce2cb7e279207b9e' o una delle relative dipendenze. Impossibile trovare il file specificato. LibreOffice_4.0.1_Win_x86_sdk .NET Framework 3.5 VS 2008 Pro This is a big issue for our office automation sw !! please check it out !
Created attachment 77961 [details] Patch for bug
Try the attached patch. It's a shot in the dark, but might fix your problem.
@Peter - please consider submitting to gerrit where it will get proper review and be pushed to larger community. As this is affecting this many people, I want to mark as NEW but we need more information. Does this prevent you from running LibreOffice at all? What operating system(s)? Everyone seeing it because of NET 4.0 framework ? Any additional information helpful, is this on install or when running LibreOffice? Marking as NEEDINFO, please see this link for proper steps in reporting a bug: https://wiki.documentfoundation.org/BugReport Once you provide steps and all info, mark as UNCONFIRMED and we will triage ASAP. Thanks for helping
Michael -- adding you despite the fact that I put it in NEEDINFO - you might be able to understand the bug even without all the relevant info. Furthermore, wanted you to take a look at the patch provided. Seems pretty serious if we can confirm
Peter - your fix looks good to me; if it compiles for Windows, can you push it ? :-)
I have the same issue. C#.net fW 4.0 Where I Apply this path?... I dont' understand. Thanks
I set to NEW as Michael has stated the patch looks good (assume this means that there is a problem to begin with). @Julieta - you cannot apply the patch unless you build LibreOffice (very unlikely) so you'll have to wait until it gets into a release.
Peter Foley committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe4ffd81045144ffb8d69ae9e5df7ef191005128 fdo#61503 fix cli_cppuhelper bootstrap error The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I now get this compilation error: cli_ure\source\native\native_share.h(65) : error C2664: 'System::Runtime::InteropServices::GCHandle::FromIntPtr' : cannot convert parameter 1 from 'System::IntPtr ^' to 'System::IntPtr'
Dropping the "gcnew" gets around that compilation error, but whether that is the right thing to do or not I have no idea. Peter, which compiler version did you fix work with?
Pushed this: commit 3a77c4fa06e02a3758222b39e6359a9f504d42b2 Author: Tor Lillqvist <tlillqvist@suse.com> Date: Thu Apr 25 12:35:49 2013 +0300 Fix compilation error after fe4ffd81045144ffb8d69ae9e5df7ef191005128 Whether it works, no idea. But on the other hand, from the dicsussion in fdo#61503 it doesn't seem as if that commit was deeply insightful either. (And how it compiled on the commit author's machine, no idea.) Change-Id: If6355b33c406e8da5bdb2bf77aaf8b2ac0c39343 cli_ure/source/native/native_share.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I assume this got broken with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4df4e9147019337fda07982c510a85d6f4c4062> "convert cli_ure/source/native to new syntax" (first introduced into libreoffice-4-0) changing the line in to_cli (cli_ure/source/native/native_share.h) from ::System::Runtime::InteropServices::GCHandle handle( ::System::Runtime::InteropServices::GCHandle::op_Explicit( intptr ) ); to ::System::Runtime::InteropServices::GCHandle ^ handle = (::System::Runtime::InteropServices::GCHandle ^)(gcnew ::System::IntPtr(intptr)); With my limited understanding of Managed C++ and .Net, the current state (see comment 16) of ::System::Runtime::InteropServices::GCHandle ^ handle = ::System::Runtime::InteropServices::GCHandle::FromIntPtr(::System::IntPtr(intptr)); reflects the original state again, just going from op_Explicit to FromIntPtr. Whatever exactly the intent of that "convert cli_ure/source/native to new syntax" change was, and whatever the reason the original code used op_Explicit rather than FromIntPtr---maybe because the former is there since .Net Framework 1.0 according to <http://msdn.microsoft.com/en-us/library/awsy2t77.aspx> "GCHandle Explicit Conversion (IntPtr to GCHandle)" while the latter only since .Net Framework 2.0 according to <http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.gchandle.fromintptr.aspx> "GCHandle.FromIntPtr Method," or maybe because the former might save a GCHandle instance instantiation (but my .Net knowledge is too limited there).
Since this is definitely a show stopper for anyone using .NET to interface with LO, can't the fix be backported to the 4.0 branch too?
I'd be happy to back-port that; but first I'd like to know that the bug is resolved in master :-) Can you try a dev-build to see if it fixes it for you checkout: http://dev-builds.libreoffice.org/daily/master/Win-x86@6/current/ hopefully that has what you need included to test it; thanks ! :-)
(In reply to comment #19) > I'd be happy to back-port that; but first I'd like to know that the bug is > resolved in master :-) > > Can you try a dev-build to see if it fixes it for you checkout: > > http://dev-builds.libreoffice.org/daily/master/Win-x86@6/current/ > > hopefully that has what you need included to test it; thanks ! :-) Good point! :-) As a matter of fact, I just installed the daily build (both LO and the SDK), tested and it doesn't work. The only difference I can spot is that now all I can report is that "an external component has thrown an exception". It must be noted, though, that the CLI SDK in master is probably broken for some other reason (cli_oootypes.dll lacks everything under com.sun.star.*, that can't be a good sign). If building LO weren't *so* beyond me :( I'd just try applying the fix to v4.0.2 (maybe creating an experimental branch) and see whether it works there.
Is there any progress on this one? This is a critical issue for me (and for everyone who uses .NET interop) ...
Having the same problem. Trying with various 4.x SDK versions - none works. .Net 4.0, Visual Studio 2012, Win 7 x 64 SDK 4.0.0.3: gives System.InvalidCastException: Unable to cast object of type 'System.IntPtr' to type 'System.Runtime.InteropServices.GCHandle'. at uno.util.to_cli<class com::sun::star::uno::XComponentContext>(Reference<com::sun::star::uno::XComponentContext>* x) at uno.util.Bootstrap.bootstrap() SDK 4.2.0 alpha (master~2013-07-11_04.05.08_LibreOfficeDev_4.2.0.0.alpha0_Win_x86_sdk.msi from today's daily (18th July 2013)) System.TypeLoadException: Could not load type 'unoidl.com.sun.star.frame.XComponentLoader' from assembly 'cli_oootypes, Version=1.0.8.0, Culture=neutral, PublicKeyToken=ce2cb7e279207b9e'. seems the 4.2.0 alpha is missing quite a lot of the unoidl.com.sun.star types; not suprising, as it has ~5KiB, while the 4.0 has ~951KiB. SDK 4.1.0.2: Same problem as 4.2.0, hardly any types. SDK 3.6.6 with LO 4.x uninstalled and LO 3.6.6 installed, and .Net 3.5: WORKS
Managed to patch and compile cli_ure, took only a day or two. If someone needs the 5 dlls, please drop me a note (LibreOffice 4.0.4.2, .Net 4.0) Sebastian
Comment on attachment 77961 [details] Patch for bug found integrated as commit fe4ffd81045144ffb8d69ae9e5df7ef191005128 marking as "obsolete" so it does not show up in bugzilla searches.
reading the comments i get the impression that the problem is fixed in LO 4.1.0; please re-open if that is not the case.
(... and forgot to mention: the problem mentioned in comment #20 should be fixed in LO 4.1.4 see bug 67725)
When accessing libreoffice from our program via cli .net integration. I get the following message. Could not load file or assembly 'cli_cppuhelper, Version=1.0.22.0, Culture=neutral, PublicKeyToken=ce2cb7e279207b9e' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) I installed libreoffice 4.2.0.4. Is this bug resurfacing. And how can we fix it.
You need to use the strong name tool "sn.exe" from the .Net 4.0 SDK. It can be found - if installed - in C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools (note that (1) there are different versions for win7 vs. before, and (2) officially it is not to be used for deployment ...) just add it to the path and call (where the dll is) sn -Vr cli_cppuhelper.dll I'm not a LO developer, so I can't tell you *why* there is no strong name validation in the cppuhelper, just how to use it anyway ..
I did just that: added : C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin to the path and executed the command. sn -Vr cli_cppuhelper.dll Microsoft (R) .NET Framework Strong Name Utility Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved. Verification entry added for assembly 'cli_cppuhelper,CE2CB7E279207B9E' And dit the same for the cli_basetypes.dll. Recompile the application and presto it worked again. The question remaining is if I instal the application with my user should I sign the dll's before the users can use the app. Shouldn't this be done in the installation script?
please don't re-open bugs for similar problems that don't have the same cause... the "strong names validation" bug in 4.2 is now bug 75206