This is probably nothing new, but something I just recently became aware of, using my build from the libreoffice-4-0 branch. I am not sure if I have interpreted my testing correctly, please discuss.
Firstly, a vanilla Windows XP SP3 has no .NET Framework on it. Not even 2.0. That doesn't seem to hurt installing LibreOffice's managed code DLLs (cli*.dll, policy.1.0.cli_*.dll). Both my build and the TDF build installs fine. However, if the XP machine has .NET 3.5 (as the test virtual machine I usually have used has, I don't recall why it has it), you will see a mysterious and rather useless error message during installation: "Error 1304.Error writing to file cli_uretypes.dll. Verify that you have access to that directory." After that the installation fails. For the TDF LibO-Dev_4.0.0.0.beta1_Win_x86_install_multi.msi I get otherwise the same error, but for cli_basetypes.dll. If you look in the msiexec log file (at least if you have run msiexec from the command line, and turned on verbose logging), you will see: "The assembly is built by a runtime newer than the currently loaded runtime, and cannot be loaded." But of course, the log file doesn't say which versions exactly it is referring to... As far as I can see from link -dump -clrheader, the cli_uretypes.dll requires .NET 2.05, which certainly should be available on the machine, as it has even .NET 3.5? Have we had any bug reports about this problem earlier? Or have we been lucky, and always built the TDF builds on machines with a very conservative selection of tool-chain(s) installed, or something?n As far as I could see, the relevant tools that got used for my test are: C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe: Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.5420 for Microsoft (R) .NET Framework version 3.5 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\al.exe: Microsoft (R) Assembly Linker version 9.0.30729.1 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe: Microsoft (R) .NET Framework Strong Name Utility Version 3.5.30729.1 I will try to tweak the PATH used in config_host.mk and see if I can make the installation error go away if I use older versions of csc.exe and/or al.exe and sn.exe... Or could it be the MSI tool-chain used that causes this? I see in config_host.mk that also Windows SDK 7.1A is involved in PATH, maybe they get picked up from there, hmm. Anyway, we probably need to make sure in configure.ac (and oowintool which is still used in the 4.0 branch) that we use exactly the right versions of tools. not too new ones, to avoid this problem. Or is this a problem? Maybe we just should note in the release notes that we require either the newest .NET Framework client (4.0) to be installed, or none at all (which can be the case only on XP, I think). If we do this, we probably should add some test to the installer so that it checks the presence of .NET and gives an understandable error message if a too old version is detected. --tml _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
