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]

Reply via email to