Using VS2019 & VS2022 in parallel will result in deregistration of keyboard binding for the currently not used VS version

[Another-Ralf]

When switching between two VS Versions (because of different project needs) the dpack keyboard bindings seem to be removed when starting one of the VS versions while the other is still running.

To replicate behavior:

• Start VS2022 set keybinding via the explicit button "keyboard shortcuts" in the dpack option for this. Check that binding works

• Close VS2022

• Start VS2019 set keybinding via the explicit button "Assign Shortcuts" in the dpack option for this. Check that binding works

• Close VS2019

• Start VS2022 and check if dpack keybindings work Presumably the work

• Don't close VS2022

• Open VS2019 (so both VS version run in at the same time) check keybindings and see that they don't work in VS2019.

That happens vice versa so starting VS2022 while VS2019 is running VS2022 will no longer know the keybindings for dpack also.

I used the ALT+U shortcut for opening the filebrowser to check keybindings.
Expectation is surely they work permanently in both VS version without the constant need to reapply bindings.

I just found the logs for VS2019 don't know where the one for VS2022 ended up.
DPack.log

[sergey-visual-studio]

This is something I ran into myself early on in VS 2022, and having both VS 2019 and VS 2022 installed on the same box. On my machine start page contents gets consistently cross populated between 2 versions as well as some other settings like project location for instance. To me it squarely points at compatibility with an older version type issue in VS itself. I never bothered submitting an issue against that, even though I considered doing that. In my day job I spend all of my time in VS 2022, which is the only VS version on my work machine, hence my never submitting it.

So I'm afraid unless MS is made aware of this issue and chooses to fix it, there isn't much I can do on my end.