https://bugs.documentfoundation.org/show_bug.cgi?id=161048
--- Comment #3 from V Stuart Foote <[email protected]> --- Alright, your install method is quite different than what is suggested. Performing an MS Installer "Administrative" aka. "server" install, done with the /a flag simply extracts content of the installer msi. And technically it does not install the package. Each package so extracted stands alone, and can/should be configured to not use your user profile. With this /a install and config, there should not be a "LibreOfficeDev" folder entry in your %APPDATA% (C:\Users\<username>\AppData\Roaming) folder. Only if you run the installer as for a default /i flag will you get an install, which by default will write to C:/Program Files/LibreOfficeDev. And to fully integrate with Win os/DE you'd have to add a "WRITER_REGISTRY=1" flag to the install (as msi package for the dev builds have that disabled and set 0). Doing the /a installs are simpler to cleanup, use TARGETDIR=<fullPathToInstall>, and adjust the bootstrap.ini Userinstallation= stanza to use $ORIGIN rather than $SYSUSERCONFIG. Then simply deleting the folder will remove all trace. Otherwise, you need to clean the registry--and config of each of the dev builds will interfere with all others. Though fortunately with defaults--the dev builds should not touch the release build configs. If you want to install/test like that, what I'd suggest is to clear the per user profile that links to you D:\LO\Alpha\program used in your custom installs. Even though install is to your D: drive, your user profile is going to be C:\Users\<yourusername>\AppData\Roaming\LibreOfficeDev. Delete it to clear the profile (on next launch that will recreate with defaults. See if that clears the zombie soffice.bin at close of the recent build. -- You are receiving this mail because: You are the assignee for the bug.
