Installing our CLI DLLs on Windows XP SP3 with .NET 2.0 and 3.5 (but no newer) fails

[Tor Lillqvist]

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