first please note that I noticed this from the main 3.5 branch, I err in the side of caution by putting 3.5.0 as the version ( I will check the last rc too ) In a vba module ( just open Excel or Word, open the VBA IDE and insert the following procedure into a module and run ) Sub Test Set oService = CreateObject("com.sun.star.ServiceManager") '<- will fail Set oDesktop = oService.createInstance("com.sun.star.frame.Desktop") End Sub I get an unable to create ActiveX object ( or some such error ) looking in the registry there are no entries relating to "com.sun.star.ServiceManager" This is a regression, in the past mostly bugs to do with using COM automation to access are from corporate users e.g. accessing Libreoffice functionality via .net or vb ( or sometimes even c++ using OLE/COM )
in 3.3.4 and 3.6.0 master on Fedora 64 bit it outputs: Module cannot be loaded; Invalid format
(In reply to comment #1) > in 3.3.4 and 3.6.0 master on Fedora 64 bit it outputs: > Module cannot be loaded; Invalid format well it's never going to work on a 'nix :-) this is a windows only bug
not reproducible in 3.4.2 and 3.5.0 beta 3 on Windows XP 32 bit
the official 3.5 doesn't seem to have this problem, I wonder is it perhaps like I asked on the dev-list something specific to developer builds :/
http://dev-builds.libreoffice.org/daily/Win-x86@6-fast/libreoffice-3-5/current/libreoffice-3-5~2012-02-16_06.49.50_LibO-Dev_3.5.1rc0_Win_x86_install_en-US.msi exhibits the problem for me
It happens with LODev only, not with release builds. Noel, do you think it needs to be fixed? LODev should be parallelly installable with LibreOffice release.
(In reply to comment #6) > It happens with LODev only, not with release builds. Noel, do you think it > needs to be fixed? LODev should be parallelly installable with LibreOffice > release. thanks for checking that, imo would be *really* nice to fix but not a blocker if it doesn't affect the release ( I will remove it from the most annoying ), it is certainly something simple in the installer builder code as the Registry,idt files seem to contain what looks like correct stuff. I don't understand the installer foo and didn't see what I feel must be an obvious error. I would bet it's related to some naming difference of meta data the installer tooling uses that is failing due to lo35 vrs lo35dev or whatever the naming conversion difference is
@Noel: It would cause confusion, if two applications (LibO release and LibODev) register themselves as server, wouldn't it? However, you can force the installer to register those keys, just run: msiexec /i LibODev<whatever>.msi WRITE_REGISTRY=1
(In reply to comment #8) > @Noel: It would cause confusion, if two applications (LibO release and LibODev) > register themselves as server, wouldn't it? However, you can force the > installer to register those keys, just run: > msiexec /i LibODev<whatever>.msi WRITE_REGISTRY=1 ok, I see your point, I just don't think about parallel install since I use windows so infrequently. It is still confusing I guess because sure some people will install the dev-builds and find that some things like this don't work ). I wonder can you as easily force the installer to delete those registry items ( I am showing my lack of windows knowledge here ) So, anyway it seems you are saying that this behaviour is intentional if so then lets close the bug :-)