Created attachment 71482 [details] Install error message In preparation for the Test Marathon, I downloaded the LO 4.0 beta via bittorrent and tried to install it via "custom" instead of "typical" installation. The modification I did was to change the install drive from "c:\" to "d:\". LO installation failed. Attaching images of error found.
Created attachment 71483 [details] Install error message 2
I'm hunting down someone to test this out, can you install on your C:/ successfully?
I tried a "typical" install, without changing any settings, on the c:\ drive and still got the same error message "Error 1304.Error writing to file cli_basetypes.dll. Verify that you have access to that directory." I will now try to download the file directly (not using utorrent, and then install).
You need to install .NET Framework (Client) 4.0. We are aware of this problem. We need to either make this requirement more obvious, or make it not be a requirement. The useless error message is Microsoft's fault, though. http://nabble.documentfoundation.org/Installing-our-CLI-DLLs-on-Windows-XP-SP3-with-NET-2-0-and-3-5-but-no-newer-fails-td4023477.html
Thanks for the information, perhaps the installer could check for the .Net 4.0 framework as a pre-requisite. I will install framework, and try installing again.
dhirenjani: Please tell us what Windows version you are using, and whether you had any .NET Framework installed before.
I have Windows Vista Home Premium with SP2 A few months back, I had removed .Net 4.0 and retained only .Net 3.5 SP1 With only .Net 3.5 SP1, LO 4.0 beta did not install and I ran into the error message. After downloading and installing .Net 4.0 client framework, I was able to install LO 4.0 beta1, using custom install method. You can close this bug.
Wow - what a sucky bug in Microsoft's infrastructure. Is there no way we can defeat it (for this fairly minor piece of .Net integration code that almost no-one uses ?). I wonder, could we detect the wrong SDK and simply turn off that .Net integration in the installer, or even default to turning it off in extremis for Beta2 ? ...
Michael: Read the email thread, Andras has a good idea what to do, and it sounds as if it would do exactly what you say.
dhirenjani: No, we don't want to close this bug as it *is* a bug that you can't install LO if you happen to have some, but not the latest, .NET installed...
*** Bug 58296 has been marked as a duplicate of this bug. ***
I place a quote here from a mail from Andras Timar: " for testers there is an easy workaround. Well, there are two. 1. Install .NET 4.0. -- OR -- 2. Install LibreOffice from the command line: msiexec /i LibO-Dev_4.0.0.0.beta1_Win_x86_install_multi.msi REQUIRED_DOTNET_VERSION=4.0.0.0 "
*** Bug 58402 has been marked as a duplicate of this bug. ***
*** Bug 58621 has been marked as a duplicate of this bug. ***
This happened with LO 4.0 Beta 2, I have tried it on Windows 7 Ultimate, actually don´t know what version of .net it have.
This is confirmed, marking as NEW, setting priority to HIGHEST
Does this commit https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=43c704aa24c48cd8b20049901d3d0bad20dd801a mean that it is a feature, not a bug? I'm not kidding. Best regards. JBF
ah looks like it may be fixed, thanks for the link, once it's verified as fixed (RC is coming out next week) we'll mark as RESOLVED
JBF: As far as I know, if you don't have any .NET at all (as in a vanilla latest-SP XP), there is no problem in installing. The problem happens if you have *some* .NET but not 4.0. And I don't see what problem there is in requiring 4.0 then in that case, if the machine already has some .NET anyway. Doesn't Windows Update recommend installing .NET 4.0 anyway?
Won't this fix fail when newer .NET will be released, i.e. 5.x will be installed and LibO will try to copy its 4.x version? Or do I not understand something?
(In reply to comment #19) > JBF: As far as I know, if you don't have any .NET at all (as in a vanilla > latest-SP XP), there is no problem in installing. The problem happens if you > have *some* .NET but not 4.0. And I don't see what problem there is in > requiring 4.0 then in that case, if the machine already has some .NET > anyway. Doesn't Windows Update recommend installing .NET 4.0 anyway? I am afraid my English is too bad to express correctly what I mean.;-) I understood the commit as: now .NET ≥ 4.0 is explicitly required. So now, it is not a bug if the installation fails until you installed all needed dependencies. No problem for me. I imagine that this change implies there is some message to the user which tell him to upgrade .NET before to complete the LO installation. Best regards. JBF
Ruslan, I don't understand what you mean with "copy its 4.x version"? LO does not "include" the .NET Framework. It just includes some (relatively unimportant and never used by most users) dlls that are managed (.NET) code. (To be used by extensions written in C#.)
Hello I reproduce the bug (error 1304 cli_basetypes.dll) with Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0) and Windows XP Pro Version 2002 SP3 According to the windows control panel: -Microsoft .NET Framework 1.1 -Microsoft .NET Framework 1.1 French Language Pack -Microsoft .NET Framework 2.0 (In reply to comment #12) > " for testers there is an easy workaround. Well, there are two. > > 1. Install .NET 4.0. > -- OR -- > 2. Install LibreOffice from the command line: > msiexec /i LibO-Dev_4.0.0.0.beta1_Win_x86_install_multi.msi > REQUIRED_DOTNET_VERSION=4.0.0.0 " I successfully tested the second workaround. Thank you for that Regards Pierre-Yves
Pierre-Yves: and what happened then when you passed that property setting on the command line? No warnings or other messages, no windows telling you that you need .NET 4.0? Then that property works is even better than I thought. (Now that I think about it, Andras probably described it just like that, but I had forgotten.)
(In reply to comment #24) > Pierre-Yves: and what happened then when you passed that property setting on > the command line? No warnings or other messages, no windows telling you that > you need .NET 4.0? This... (no warnings or other messages). And that is what I meant by "successfully tested". Sorry for my lack of precision... The software starts without warning or error ... I do not know if such a message can occur during use, but I doubt it. Regards Pierre-Yves
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=43c704aa24c48cd8b20049901d3d0bad20dd801a So we require .NET 4.0 from now on. If user does not have .NET 4.0, then installer will silently continue and will not install cli ure stuff.
(In reply to comment #26) > https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff; > h=43c704aa24c48cd8b20049901d3d0bad20dd801a > > So we require .NET 4.0 from now on. If user does not have .NET 4.0, then > installer will silently continue and will not install cli ure stuff. What are the consequences in terms of functionalities when cli ure stuff is not installed? If there is consequences, we could mention them in the release notes. Best regards. JBF
As Tor mentioned in comment 22, it is for extensions written in C#. I don't know about such extension at all. The risk is near 0. On the other hand we are looking forward to getting bug reports related to this part of code, so we know if anybody out there is using it.
Hello (In reply to comment #26) > If user does not have .NET 4.0, then > installer will silently continue and will not install cli ure stuff. Confirmed with Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799) same config as comment 23 Windows XP Pro Version 2002 SP3 According to the windows control panel: -Microsoft .NET Framework 1.1 -Microsoft .NET Framework 1.1 French Language Pack -Microsoft .NET Framework 2.0 Thank you Pierre-Yves
See #59232. Still a problem on 4.0.0.4 (first official v4 release)
(In reply to comment #30) > See #59232. Still a problem on 4.0.0.4 (first official v4 release) make that 4.0.0.3 - keyboard (== me) error.
Gordon: > make that 4.0.0.3 - keyboard (== me) error. What are the symptoms of that ? do we truly fail to install unless .Net Framework 4.0(Client) is installed ? - if so that would be simply horrible. The correct behavior would be to silently disable the .Net pieces in this case. Is that what we are doing ? can you provide more data on the machine you tested this on and the outcome ?
Yes. A complete failure to install. It just unwinds (and, if you had 3.6 there before, that is now gone and you are left with no LO at all). As I said - I has to install .Net 4.x (I did 4.5) to get an installation to complete.
Andras - that sounds pretty hideous; how can we debug that / help out with it ? We got quite a significant jump in the proportion of Linux & Mac installs with the 4.0 release - it would be sad if people downloaded & then could not install en-masse. Gordon - can you reproduce this on a clean machine - and if so - what exact OS/Version etc. ?
I'll test it tomorrow. I guess it happens on XP, because Windows 7 has .Net 4.0 by default. So I'll test the following scenarios: Clean Windows XP, no .Net, 3.6 -> 4.0 upgrade Clean Windows XP, .Net 2.0, 3.6 -> 4.0 upgrade Clean Windows XP, no .Net, 4.0 install Clean Windows XP, .Net 2.0, 4.0 install
As noted in Bug 59232 (which I did reference, even though I'd forgotten how to get an automatic link set-up) the problem occurred for me on a Win7, 64-bit system which only had .Net 2.0. This is a work-supplied laptop. So don't ask me why it only has .Net 2.0, but it does (or rather, it did).
I've tried this on Windows XP virtual guest, and having removed LODev4 which was installed using workaround 2 from comment 12, I cleanly installed LO 4.0.0.3 without problems, i.e. not needing any workarounds. So, I've not been able to reproduce the problem with currently downloadable release.
I could not reproduce. Neither on Windows XP 32-bit (with and without .Net 2.0), nor on Windows 7 64-bit (with built-in .Net 2.0). 3.6.5.2 -> 4.0.0.3 upgrade worked, standalone 4.0 install worked. When .Net 2.0 was installed, then 3.6 installed .Net assemblies, as expected. During upgrade to 4.0 these were removed, as expected. 4.0 installer did not try to install them (DotNetCheck did not report a useable .Net version). I mark this RESOLVED FIXED again.
So the fact that others are reporting it as a problem on Win7 64-bit (see Bug 59232) doesn't influence anyone.
*** Bug 59232 has been marked as a duplicate of this bug. ***
(In reply to comment #39) > So the fact that others are reporting it as a problem on Win7 64-bit (see > Bug 59232) doesn't influence anyone. No, because the screenshot in there was made of 4.0.0.0beta2, before the fix.
Ah...I didn't add a screenshot there as it didn't add any additional info. But I *did* update the version and platform to indicate the latest release which had shown the problem. It turns out I have another 64-bit Win7 desktop at work (not much used - only just occurred to me that it is there). I'll have another go on that one. And remember that this will be Windows Professional, not Windows Home (if it might make any difference).
Just a reminder ,version field is the oldest version that shows the issue - it should NOT be updated to a newer release if a newer release shows the issue. We use comments to track what versions have been tested & when a bug is in NEW status it is known that it's still an issue so no need to change verisn
>> It turns out I have another 64-bit Win7 desktop at work (not much used - only just occurred to me that it is there). >> I'll have another go on that one. That was the theory. Except that one doesn't have any .Net on it at all. I can only assume the the first system has .Net2.0 on it as it was prepped to mirror my previous XP setup (which presumably had it). Looking at the .Net 2.0 download page indicates it might be a real problem to add, along with required updates. So I'll leave it as being the result of an oddly set-up system.
Just an update on my failures with this in case anyone comes across this in the archive. Since having .net4.5 on my system broke other things (which use the latest .net, but can;t handle .net4.5) it was removed. I've just done an update to 4.0.2.2. This failed with the "Error 1304. Error writing to file cli_basetypes.dll" pop-up. However, this time round I was able to install using the Command Line method mentioned in Comment 12.