Actually, I notice there's more than just workspaces that are shared between versions and that makes no sense... The config.properties, blcli-log.cf and the images folder... There's a folder for each version too, but that's kept outside of them, why??
I’m not sure – imo all that stuff needs to be split out because i’ve run into weird display issues when switching between different versions on the same system. now granted – having multiple versions installed isn’t very common which is probably why this doesn’t have much attention.
When testing an upgrade this would be common until all environments are upgraded. I think it should be considered a defect because it should be isolated in their own version directory. The launcher.ini file of the rcp client has some options to change the location of the data and config files. I managed to configire the ini of each version to a static location, so each is kept in its own workspace and data directory. That works but I can only open one console of each version at a time because it won't create additional workspaces like it does by default.
C:\Program Files\BMC Software\BladeLogic\NSH\jre\bin\javaw.exe
-Djava.library.path=C:\Program Files\BMC Software\BladeLogic\NSH/bin;C:\Program Files\BMC Software\BladeLogic\NSH/br/stdlib
-Dblx.cmrootdir=C:\Program Files\BMC Software\BladeLogic\NSH/br
-Dblx.cmlibdir=C:\Program Files\BMC Software\BladeLogic\CM/rcp/plugins/com.bladelogic.client.jars_1.0.0/lib
The only thing is that it still creates a shared config.properties, client_keystore.pkcs12.PEM and images folder in the %appdata%\BladeLogic folder, so there's still a potential for conflicts and graphical issues when mixing versions even with this trick.
Another solution would be to provide a "portable" version of the console, which would all reside in the same folder. Just unzip and go, and maybe run a post-unzip batch or something to do some registry config. There are applications like ThinApp as well that can help by creating a virtual "container" for the app, but that's not a freebee...
?yeah - generally i agree
as for the defect bit - if you can reproduce that and show it's a problem, i'd open a ticket and have support file a defect. i'd expect that w/ concurrent gui installs there's an assumption that you can run more than one at a time, and run them in different orders w/o messing up the files from each other.
Yeah it's also my conclusion. The fact that the installer has the explicit option to install a new instance in a different directory and doesn't warn about version conflicts (other than for the app server), leads to the assumption that you can mix versions together without problems.
It's easy to reproduce, at least between 8.5 and 8.9. The steps are in the the original post. I'll open a ticket.