Hi Marten,
Marten Feldtmann wrote:
Ok,
I try to give some more information. On my development machine I have
.NET 1.1, .NET 2.0 and .NET 3.0 installed. On this machine I use OO 2.3
and all development is done using OO 2.3. I use OO to create documents
on demand and on my machine everything is working as expected.
Original on the target machine was only .NET 2.0 but I also installed
.NET 1.1 on that machine. Installed was also OO 2.2. I've several
machines like this in our network ... and all have the same behaviour.
If I deploy my application I've learned, that I have to deliver my
versions of (based on OO 2.3) the following four libraries:
* cli_basetypes.dll (1.0.7.0), * cli_cppuhelper.dll (1.0.10.0), *
cli_types.dll (1.1.10.0), * cli_ure.dll (1.0.10.0)
I have a very simple deployment - I put all my files into a single
directory and add these four libraries to this directory.
This should not be necessary since OOo installs the libraries into the
GAC. This is also dangerous because a new OOo version typically brings
new types in cli_types.dll. When these are transferred to the client
which uses an old cli_types.dll then the CLI-UNO bridge certainly
terminates.
If I do NOT add these libraries, the .NET (e.g.) gets a request to bind
version 1.1.10.0 of cli_types.dll and it fails, because it has only
version 1.1.7.0 (the version from from OO 2.2) and there are no
rebinding instructions to rebind all the stuff to version x (based on OO
2.3).
With every new version of OOo the assembly versions are incremented. Now
client programs build with previous programs would not run anymore.
Therefore OOo also installs a policy assembly for each assembly, for
example policy.1.1.cli_types.dll which does a binding redirect for the
assembly. That is, the runtime is told to use version 1.1.10 although
your assembly was build with 1.1.7. Here is an example of a policy
configuration file:
<?xml version="1.0"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="cli_types"
publicKeyToken="ce2cb7e279207b9e"/>
<bindingRedirect oldVersion="1.1.0.0-1.1.10.0"
newVersion="1.1.11.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Please look in your GAC if all four policy assemblies are available. The
policy configuration files can be found as plain text in the GAC, for
example
C:\WINDOWS\assembly\GAC\policy.1.1.cli_types\9.0.0.0__ce2cb7e279207b9e\cli_types.config
CLI programs can be configured to use or not use publisher policy files.
This can be done by the .NET configuration program which is part of the
runtime 1.1 and part of the SDK in version 2.0.
Publisher policy is by default enabled.
However, I suppose this could also be overwritten by the
enterprice.config, or machine.config (for example in
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG). Make sure this is
not the case.
Please try out first to use the assemblies in the GAC.
Joachim
The result is a simple error message on the target machine:
System.IO.FileNotFoundException: Die Datei oder Assembly cli_types,
Version=1.1.10.0, Culture=neutral, PublicKeyToken=ce2cb7e279207b9e oder
eine Abhängigkeit davon wurde nicht gefunden. Das System kann die
angegebene Datei nicht finden.
Dateiname: cli_types, Version=1.1.10.0, Culture=neutral,
PublicKeyToken=ce2cb7e279207b9e
bei OpenOffice.TextDocHelper..ctor(Boolean hiddenFlag)
=====================================================================
If I add these libraries the .NET framework searches in the executing
directory and find my deployed versions of these dll's and seems to bind
them but errors come later on the target machine:
System.Runtime.InteropServices.SEHException: Eine externe Komponente hat
eine Ausnahme ausgelöst.
bei cppu.bootstrap(Reference<com::sun::star::uno::XComponentContext>* )
bei uno.util.Bootstrap.bootstrap()
bei OpenOffice.GeneralDocHelper.connect(String[] args) in
D:\programmierung\ES2005-1\OpenOfficeConnection\OpenOfficeConnection\GeneralDocHelper.cs:Zeile
55.
bei OpenOffice.GeneralDocHelper..ctor(Boolean hiddenFlag) in
D:\programmierung\ES2005-1\OpenOfficeConnection\OpenOfficeConnection\GeneralDocHelper.cs:Zeile
35.
bei OpenOffice.TextDocHelper..ctor(Boolean hiddenFlag) in
D:\programmierung\ES2005-1\OpenOfficeConnection\OpenOfficeConnection\TextDocHelper.cs:Zeile
25.
(does not matter if admin or normal user)
=====================================================================
If I add the OpenOffice 2.2 installation path (...\program) to PATH I
get a different error on the target machine:
unoidl.com.sun.star.uno.RuntimeException:
[map_to_uno():[]com.sun.star.beans.PropertyValue] conversion failed
[map_to_uno():unoidl.com.sun.star.beans.PropertyValue.Value
[map_to_uno():any] could not convert type!
Server stack trace:
Exception rethrown at [0]: bei
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg)
bei
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 type)
bei
unoidl.com.sun.star.frame.XComponentLoader.loadComponentFromURL(String
URL, String TargetFrameName, Int32 SearchFlags, PropertyValue[] Arguments)
bei OpenOffice.TextDocHelper.initDocument(Boolean hiddenFlag) in
D:\programmierung\ES2005-1\OpenOfficeConnection\OpenOfficeConnection\TextDocHelper.cs:Zeile
93.
bei OpenOffice.TextDocHelper..ctor(Boolean hiddenFlag) in
D:\programmierung\ES2005-1\OpenOfficeConnection\OpenOfficeConnection\TextDocHelper.cs:Zeile
28.
=====================================================================
Then I installed OO 2.3 on the target machine (changed the PATH variable
to the
original content - this means: NO OO 2.3 in the path) and get the same
XComponentContext exception as mentioned above.
=====================================================================
Then I change the PATH variable to point to the OO 2.3 directory
(..\program\)
all is working.
=====================================================================
Following my experience on some other machines here I have to make sure,
that
ALL machines have OO 2.3 and PATH must include the OO2.3 program directory
and then the stuff may work. Another problem here is, that it is not
possible
to retrieve the installation path of OO 2.3 when working as a normal user -
the security issues with that simple deployment do not allow this.
After all I would say, that the whole deployment for .NET based system
concerning
OpenOffice simply does not work.
But perhaps you have some hints to make this work ...
Marten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
