Description: Hi, I did some research in the database but could not find any clearly related bug report. My client is using OpenOffice (OO) which is being controlled through a .NET application. We want to make the move to LibreOffice (LO) but want to support multiple version of it in parallel with OpenOffice. The cli_ assemblies to access LO from .NET of all the LO version I have looked at (5.3.x and 5.4.0) have the same assembly version so e.g. cli_basetypes.dll has version 1.0.19.0 and the same PublicKeyToken across all LO versions I have looked at; it also shares the same assembly versions with (at least) OO 3.4.0. That makes it difficult if not impossible to properly load the correct assemblies. The cli_ assemblies get installed into the Global Assembly Chache (GAC) by default and in the loading process the GAC always gets priority over local assemblies. That definitely makes it impossible at this point to use OO 3.4 and any LO version in parallel because it is unclear which assemblies are installed in the GAC and which get preference. Please elaborate on the rationale of not versioning the cli_ assemblies with each release. If there is no reason, please consider versioning them. Thank you! Steps to Reproduce: n/t Actual Results: n/t Expected Results: n/t Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 OPR/45.0.2552.898
afaik there is nobody in the project who actually knows anything about CLI; all that's been done there in LO is that some guy migrated the code from a deprecated C++ on CLI dialect to a not deprecated C++ on CLI dialect, and the 64 bit port. so it looks like these versions are stored in: cli_ure/version/version.txt git log of that file indicates all the *_NEW_VERSION were incremented in their 3rd digit, while the *_OLD_VERSION were incremented to cover the previous value of *_NEW_VERSION, and the *_POLICY_VERSION incremented so its 1st digit matches the 3rd digit of *_NEW_VERSION. this happened once for every OOo release, 3.4, 3.3, 3.2, 3.1.1, 3.1... so i suppose we should adapt a similar approach? bumping it once per x.y branch should be enough? i predict this is not going to happen reliably unless Cloph adds it to some release-engineering checklist.
found some OOo docs on this: http://www.openoffice.org/udk/common/man/spec/assemblyversioning.html there is another file containing versions: unoil/climaker/version.txt ah! there's a script for that: cli_ure/source/scripts/increment_version.pl it's written in Perl so it can be blindly trusted to do the correct thing. so with a bit of tweaking this will upgrade all version numbers.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=17192ce5588f84192d1dd0d963622bda48566fdc tdf#108709 cli_ure,unoil: bump CLI assembly versions for 5.4 It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aac0c5a7d6e2738bc8f86327f3c2ba0a132b6354&h=libreoffice-5-4 tdf#108709 cli_ure,unoil: bump CLI assembly versions for 5.4 It will be available in 5.4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=49eadf7e55a98ec284a76bc44373150c85fa7f1e&h=libreoffice-5-4-1 tdf#108709 cli_ure,unoil: bump CLI assembly versions for 5.4 It will be available in 5.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping to Michael Stahl: is this bug fixed? if so, please close it as RESOLVED FIXED
I have just checked 5.4.1.2/5.4.2.2. and compared to 5.4.0.3 using .NET Reflector 6 cli_basetypes was versioned (from 5.4.0 to 5.4.1) cli_cppuhelper was NOT versioned; what is worse is that, beginning with 5.4 it stopped having a version (Reflector shows 0.0.0.0) cli_oootypes was versioned (from 5.4.0 to 5.4.1) cli_ure was versioned (from 5.4.0 to 5.4.1) cli_ was versioned (from 5.4.0 to 5.4.1) So overall it looks good. I guess the script Michael used wasn't able to increase a non existing version number. Fix this and this bug is dead!
there's another bug 113787 about this now, about the current state in 5.4.3. let's call this one fixed.