Bug 35108 - using dot net "cli" libraries from SDK does not work on Windows
Summary: using dot net "cli" libraries from SDK does not work on Windows
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: x86-64 (AMD64) Windows (All)
: medium blocker
Assignee: Don't use this account, use tml@iki.fi
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-08 02:02 UTC by giancarlotodone
Modified: 2011-04-13 10:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description giancarlotodone 2011-03-08 02:02:12 UTC 
We're using dotNet sdk libraries from libreoffice SDK for some office automation tasks with libreoffice. The problem is that a previously installed openoffice version (3.2.0) handles the work instead. If we uninstall openoffice leaving only libreoffice and libreoffice SDK installed, then an exception is raised

System.Runtime.InteropServices.SEHException
error code: -2147467259 
"An external component thrown an Exception" 
source: cli_cppuhelper
Comment 1 giancarlotodone 2011-03-08 02:07:46 UTC 
Don't know if this is only a trivial configuration issue about UNO, but we couldn't find any documentation about the unexpected behavior. We would like to be notified about this bug status because our system heavily rely on this office automation task.
Comment 2 Wolfgang Silbermayr 2011-03-21 06:09:23 UTC 
I can confirm this bug.

I had OpenOffice 3.2 installed on a Windows XP box, then installed LibreOffice 3.3.1 and afterwards uninstalled OpenOffice.

I tried a small test project in MonoDevelop which basically contains this one line that gets executed in the Main() method:

uno.util.Bootstrap.bootstrap();

The project references the files cli_basetype.dll, cli_cppuhelper.dll, cli_oootypes.dll, cli_ure.dll, cli_uretypes.dll. I untagged the "Use local copy" setting for all of them, so they should be used from the GAC, I think. Or maybe from the LibreOffice directory. I don't know which way Monodevelop chooses.

The project fails exactly the same way as giancarlotodone described it, when I run it using the DotNet 3.5 or 2.0 runtime.

Looking at the installed files under c:\windows\assembly, I see the following files installed:
(assemblyname / version / token / processor architecture)
cli_basetypes / 1.0.18.0 / ce2cb7e279207b9e / MSIL
cli_cppuhelper / 1.0.21.0 / ce2cb7e279207b9e / x86
cli_oootypes / 1.0.7.0 / ce2cb7e279207b9e / MSIL
cli_ure / 1.0.21.0 / ce2cb7e279207b9e / MSIL
cli_uretypes / 1.0.7.0 / ce2cb7e279207b9e / MSIL

What ist strange is that the company name in the exlorer porperties window for cli_basetypes file is OpenOffice.org, but maybe that was just forgotten to be changed to libreoffice when the package was built.
Comment 3 Wolfgang Silbermayr 2011-03-21 07:09:50 UTC 
One more thing I tried was completely uninstalling LibreOffice SDK and LibreOffice (OpenOffice had been uninstalled before), and then reinstalling LibreOffice and the LibreOffice SDK. It did not change the behaviour in any way.

The test application does fine on Ubuntu 11.04 beta with LibreOffice 3.3.
Comment 4 Wolfgang Silbermayr 2011-03-22 02:14:05 UTC 
I tried now inside a VM on a cleanly installed new Windows 7 where no OpenOffice had been installed before. I installed LibreOffice 3.3.1 and the LibreOffice SDK 3.3.1. It behaves exactly the same way.
I also tried uno.util.Boostrap.defaultBootstrap_InitialComponentContext() and it behaves the same way.
Comment 5 Wolfgang Silbermayr 2011-04-05 02:13:42 UTC 
I now printed a stacktrace, and the top entries are:
 at cppu.bootstrap(Referecnce<com::sun::star::uno::XComponentContext>* )
 at uno.util.Bootstrap.bootstrap()

the uno.util.Bootstrap.bootstrap() is the method which I called. Maybe the stacktrace helps to find the source of the problem.
Comment 6 Thorsten Behrens (allotropia) 2011-04-13 01:13:02 UTC 
Hi Tor, could you look into that one - sounds a bit like a forgotten name change, when doing the bootstrap? Maybe also rodo has an idea where to dig at.
Comment 7 Noel Power 2011-04-13 01:30:39 UTC 
#define INSTALL_PATH L"Software\\OpenOffice.org\\UNO\\InstallPath"

in cli_ure/source/native/native_bootstrap.cxx ( used to search the registry, presumably that is the incorrect key for libreoffice :-) )

I have a windows build, I will try a fix for it
Comment 8 giancarlotodone 2011-04-13 01:40:42 UTC 
By the way, what should be the object basename if i would like to access LO with reflection? 
I mean: because of the 32bit limitation using the SDK under win, now i'm playing with c# reflection and I'm creating e.g. a ServiceManager with Type.GetTypeFromProgID("com.sun.star.ServiceManager", true); and so on... but this - again - is raising OO, not LO. I understand that here the type I'm getting with "com.sun.star.ServiceManager" could be the wrong one... so what should be the name for LO??