Bug 61503 - uno.util.Bootstrap.bootstrap() throws System.InvalidCastException (.NET CLI)
Summary: uno.util.Bootstrap.bootstrap() throws System.InvalidCastException (.NET CLI)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
4.0.1.2 release
Hardware: x86 (IA32) Windows (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:4.1.0
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-02-26 10:52 UTC by milankorpas
Modified: 2014-02-19 13:54 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Patch for bug (766 bytes, patch)
2013-04-14 22:51 UTC, Peter Foley
Details

Note You need to log in before you can comment on or make changes to this bug.
Description milankorpas 2013-02-26 10:52:11 UTC
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)
Comment 1 Lafriks 2013-03-08 11:10:58 UTC
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();
Comment 2 Lafriks 2013-03-08 14:45:45 UTC
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.
Comment 3 taestom 2013-03-13 13:48:25 UTC
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
Comment 4 milankorpas 2013-03-14 11:46:18 UTC
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>
Comment 5 fabrizio 2013-03-14 16:21:44 UTC
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 !
Comment 6 Peter Foley 2013-04-14 22:51:00 UTC
Created attachment 77961 [details]
Patch for bug
Comment 7 Peter Foley 2013-04-14 22:51:44 UTC
Try the attached patch.
It's a shot in the dark, but might fix your problem.
Comment 8 Joel Madero 2013-04-16 23:03:31 UTC
@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
Comment 9 Joel Madero 2013-04-16 23:05:17 UTC
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
Comment 10 Michael Meeks 2013-04-18 10:10:52 UTC
Peter - your fix looks good to me; if it compiles for Windows, can you push it ? :-)
Comment 11 Julieta 2013-04-24 14:53:47 UTC
I have the same issue.

C#.net
fW 4.0

Where I Apply this path?...

I dont' understand.

Thanks
Comment 12 Joel Madero 2013-04-24 15:21:41 UTC
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.
Comment 13 Commit Notification 2013-04-24 21:33:57 UTC
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.
Comment 14 Don't use this account, use tml@iki.fi 2013-04-25 08:37:20 UTC
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'
Comment 15 Don't use this account, use tml@iki.fi 2013-04-25 08:40:11 UTC
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?
Comment 16 Don't use this account, use tml@iki.fi 2013-04-25 10:16:11 UTC
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(-)
Comment 17 Stephan Bergmann 2013-04-25 13:23:52 UTC
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).
Comment 18 rdeago 2013-05-08 08:40:12 UTC
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?
Comment 19 Michael Meeks 2013-05-08 09:21:14 UTC
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 ! :-)
Comment 20 rdeago 2013-05-08 10:29:18 UTC
(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.
Comment 21 kpreisert 2013-06-26 14:53:58 UTC
Is there any progress on this one? This is a critical issue for me (and for everyone who uses .NET interop) ...
Comment 22 Sebastian Brandt 2013-07-18 15:20:39 UTC
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
Comment 23 Sebastian Brandt 2013-07-20 07:50:35 UTC
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 24 Michael Stahl (CIB) 2013-11-10 12:08:07 UTC
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.
Comment 25 Michael Stahl (CIB) 2013-11-10 12:10:02 UTC
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.
Comment 26 Michael Stahl (CIB) 2013-11-10 12:14:52 UTC
(... and forgot to mention: the problem mentioned in comment #20
should be fixed in LO 4.1.4 see bug 67725)
Comment 27 jvanderduim 2014-02-18 08:39:16 UTC
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.
Comment 28 Sebastian Brandt 2014-02-18 08:44:13 UTC
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 ..
Comment 29 jvanderduim 2014-02-18 09:07:31 UTC
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?
Comment 30 Michael Stahl (CIB) 2014-02-19 13:54:48 UTC
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