Marten Feldtmann wrote:
Hello Joachim,
I've already found and looked at the policy files. They are all there
and they seem to work as expected. All libraries
are in the GAC And in my last posting I also did all the other attempts
to make it
work: I also tried NOT to deliver the libraries with my applications.
But from your answer I get several results:
* do not deliver new OO libraries with own application
*
But - I'm not totally sure about that - my application tried to start
and asked the .NET framework about "1.1.10.0"
(as an example), which is delivered with OO 2.3 - but the target machine
has only OO 2.2 and therefore only
"1.1.7.0" AND rebinding instructions for "1.1.1.0" - "1.1.6.0" to
"1.1.7.0". What is happing in case of such a request ?
This scenario does not work. You need to build your application on a
"base line machine". The target machines must have at least the same
version of OOo as the build machine.
Deploying you application on a machine with an older version of OOo is
not recommended anyway. For example, your application may use a type
that is not available in the old version. When you make an API call
providing this new type then the client will certainly die or misbehave.
Within VS2005 I told the application not to use strict versions - but
this does not seem to help.
Please read my posting again - I've tried several cases and even the OO
2.3 (source) -> OO 2.3 (target) ONLY
Use UNO_PATH instead of PATH. The value must include the program
directory. For example: C:\Program Files\OpenOffice.org 2.4\program
works, when I change the PATH variable and OO 2.3 (source) -> OO 2.2
(target) does not work at all.
That it works on my (office) machine is perhaps pure luck, because it
has the oldest installation and there was so
much work done with .NET configuration - but all other machines I tried
out are fresh installed machines where
nothing has been changed in the .NET configuration.
I'm now at home (using VISTA) trying to get my own application to run -
but no chance - always getting a
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
But now looking again at this code (while writing this) I get another
idea - this is a security exception ! Some
code is executed, which does not allowed things - I got this exception
(as an example) when trying to read
the registry keys values from the registry (as a "normal" user under
windows): to find out, where OO
is installed. Remember: my applications are only some files within a
directory. They are not installed using
some kind of installer or stuff like this - I'm not an expert in this
security area.
I will investigate.
But this does not answer my other question: interoperability with OO 2.3
development and OO 2.2 runtime.
As mentioned above.
Joachim
---------------------------------------------
Marten
Joachim Lingner schrieb:
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]
---------------------------------------------------------------------
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]
