sergey-visual-studio/dpack

Keyboard shortcuts assignment is dissapearing

esentio opened this issue · 5 comments

esentio commented

Hi,

at first, thank you very much for this extension!

I have multiple VMware virtual images with various Visual Studio versions. So far, I have been using old DPack. Recently I created new VM image with VS2019 and DPack Rx. I noticed following behavior:

VM1 - image with VS2019 and DPack Rx.
VM2 - image with VS2017 and old DPack.

  1. I start VS2019 on VM1. Everything works fine.
  2. I close VS2019 on VM1.
  3. I start VS2017 on VM2. I'm unable to use keyboard shortcuts for DPack. When I assign them via Tools > Options > DPack > "assign keyboard shortcuts" button, it works fine again.
  4. I close VS2017 on VM2.
  5. I start VS2019 on VM1. Again, I'm unable to use keyboard shortcuts for DPack Rx. When I assign them via Tools > Options > DPack Rx > "assign keyboard shortcuts" button, it works fine again.

This goes on as I switches between various old VS instances and new one with DPack Rx. In every VS, I'm logged-in with the same Microsoft account. I suppose it has something to do with synchronization of VS settings. My guess is that problem is that the same shortcut is bound to different commands (old and new DPack have different command names/ids as I see).

I don't want to turn synchronization off, since it's a nice feature. I can switch to DPack Rx in my VS2017 installations, but the problem will stay for my images with VS2015 and lower I guess. Is there something you can do about this?

Thanks,
Peter

sergey-visual-studio commented

That sounds really weird. So you are saying launching different VS versions from different VMs one after the other one messed up keyboard assignment? And the only common theme there you being signed in in VS with your VS account? I assume that's what you meant by "synchronization" there. Thanks.

sergey-visual-studio commented

Feel free to provide more information and we'll get it reopen. Thanks.

esentio commented

Sorry for late response.

So you are saying launching different VS versions from different VMs one after the other one messed up keyboard assignment?

Yes, but only if VS2019 has DPack Rx and VS2017 has old DPack. If both VS2017 and VS2019 have DPack Rx installed, it works fine.

And the only common theme there you being signed in in VS with your VS account? I assume that's what you meant by "synchronization" there.

Yes, I'm signed in both VS with my VS/MS account. By synchronization I mean Tools > Options > Environment > Accounts > Synchronize Visual Studio settings across devices checked. I suppose this synchronizes (beside other things also) keyboard shortcuts between my VS installations.

This is just my assumption, but I think following is happening:

  1. Alt + U is assigned to Tools.DPackRx.FileBrowser command in DPack Rx.
  2. Alt + U is assigned to Tools.DPack.FileBrowser.AllFiles command in old DPack.
  3. Assume that VS2019 with DPack Rx is running and works fine. Current Alt + U binding to Tools.DPackRx.FileBrowser command is synchronized to the cloud. Then I close VS2019.
  4. When I start VS2017 with old DPack, setting for Alt + U is downloaded from the cloud overwriting current local setting for old DPack in VS2017. Now, Alt + U is assigned to Tools.DPackRx.FileBrowser in VS2017, but there is no such command available in VS2017. And old keyboard shortcut assignment for command Tools.DPack.FileBrowser.AllFiles doesn't work anymore.
  5. When I reassign keyboard shortcuts in VS2017 problem goes vice versa when VS2019 is started.

I switched to DPack Rx in all my VS2017 installations, so the problem doesn't occur to me anymore. I still have couple of rarely used VMs with VS2015. I initially thought there will be the same problem when I switch between VS2019 and VS2015. But I just checked and this works fine. So maybe my assumption above is wrong. Or maybe keyboard shortcuts are synced between VS2017 and VS2019, but not between VS2015 and VS2019. I don't know.

I guess it's not worth trying to fix this. But I noticed #31. Maybe it's related.

  • 👍1
sergey-visual-studio commented

Yes, but only if VS2019 has DPack Rx and VS2017 has old DPack. If both VS2017 and VS2019 have DPack Rx installed, it works fine.

That's good to know.

I switched to DPack Rx in all my VS2017 installations, so the problem doesn't occur to me anymore.

I see, so you're saying it happens with old DPack version. I assume that's for VS 2017, right? Could you provide me with that DPack version? I can track down old pre-DPackRx code base and confirm but I suspect I know what I'll find there. I used to retrieve one of the key extensibility objects via some documented way, which had always looked suspicious to me. I grab some well-known COM object and proceed to assign the shortcuts using that. It's likely either broken in one of the later VS versions, cause it supposed to be re-routed to new VS variant, or broken on me end where it's compiled under one VS to be used on all supported VS versions. The good part is that it's been refactored in DPackRx code base.

I guess it's not worth trying to fix this.

Yeah, it's not I'm afraid.

I'd suggest not using automatic shortcut assignment where that type of conflict is expected and assigning them yourself using Tools|Options dialog.

Thanks for shedding more light on this issue.

esentio commented

I see, so you're saying it happens with old DPack version. I assume that's for VS 2017, right?

Yes, it happened when VS2017 had old DPack installed and VS2019 had new DPack Rx.

Could you provide me with that DPack version?

Unfortunately no. Few days after I created this issue in June, I uninstalled old DPack in all my VS2017 installations and moved to DPack Rx. Now, I have everywhere (in VS2017 and VS2019) only newest DPack Rx and it works without any problems.

As far as I remember, there was no update of DPack (old or Rx) available in June. So I guess the problematic version was whatever was latest in June.