"Open Terminal Here" can't be used with both the dev build and preview at the same time #8917

Closed
opened 2026-01-31 01:41:21 +00:00 by claunia · 9 comments
Owner

Originally created by @zadjii-msft on GitHub (Jun 8, 2020).

The Dev build one seems to always stomp the preview one.

  • Is this because they share the same Verb string? This is easy to fix
  • Or maybe is this because they share the same ClsId? This would be annoying to fix.
Originally created by @zadjii-msft on GitHub (Jun 8, 2020). The Dev build one seems to always stomp the preview one. * Is this because they share the same `Verb` string? _This is easy to fix_ * Or maybe is this because they share the same ClsId? _This would be annoying to fix_.
Author
Owner

@KUTlime commented on GitHub (Oct 17, 2020):

@zadjii-msft Maybe you could solve this problem prior to Terminal v2.0 by OpenHere module.

@KUTlime commented on GitHub (Oct 17, 2020): @zadjii-msft Maybe you could solve this problem prior to [Terminal v2.0](https://github.com/microsoft/terminal/milestone/22) by [OpenHere](https://github.com/KUTlime/PowerShell-Open-Here-Module) module.
Author
Owner

@zadjii-msft commented on GitHub (Oct 17, 2020):

image

Yea pretty sure I can't look at that, sorry. I'm not a expert in software licensing, but I know I can't look at GPL code.

@zadjii-msft commented on GitHub (Oct 17, 2020): ![image](https://user-images.githubusercontent.com/18356694/96349631-6a44a100-1076-11eb-9de5-24d6cfb96eee.png) Yea pretty sure I can't look at that, sorry. I'm not a expert in software licensing, but I know I can't look at GPL code.
Author
Owner

@DHowett commented on GitHub (Oct 18, 2020):

Regardless of how other shell extensions do it, if they’re not packaged applications (appx/msix) they will not be encountering or have had to work around this issue and will therefore not be a good model for how to fix it.

This is a limitation in the windows platform with regards to shell extensions in packaged applications.

@DHowett commented on GitHub (Oct 18, 2020): Regardless of how other shell extensions do it, if they’re not packaged applications (appx/msix) they will not be encountering or have had to work around this issue and will therefore not be a good model for how to fix it. This is a limitation in the windows platform with regards to shell extensions _in packaged applications_.
Author
Owner

@KUTlime commented on GitHub (Oct 18, 2020):

@zadjii-msft You got it all wrong. The module will not fix the problem for Windows Terminal as an application, it will solve the problem for you as a user of Windows Terminal.

@KUTlime commented on GitHub (Oct 18, 2020): @zadjii-msft You got it all wrong. The module will not fix the problem for Windows Terminal as an application, it will solve the problem for you as a user of Windows Terminal.
Author
Owner

@zadjii-msft commented on GitHub (Oct 18, 2020):

@KUTlime Ah, thanks for the clarification. As one of the maintainers of the Terminal, I'm actually less concerned about using this myself, but more just implementing the fix for the Terminal so this bug won't affect other users ☺️

@zadjii-msft commented on GitHub (Oct 18, 2020): @KUTlime Ah, thanks for the clarification. As one of the maintainers of the Terminal, I'm actually less concerned about using this myself, but more just implementing the fix for the Terminal so this bug won't affect _other users_ ☺️
Author
Owner

@KUTlime commented on GitHub (Oct 18, 2020):

@zadjii-msft Sure, no problem. Maybe my advice help someone else. 😉

@KUTlime commented on GitHub (Oct 18, 2020): @zadjii-msft Sure, no problem. Maybe my advice help someone else. 😉
Author
Owner

@KalleOlaviNiemitalo commented on GitHub (Feb 3, 2021):

I have Windows Terminal 1.4.3243.0 and Windows Terminal Preview 1.6.10272.0, and when I choose "Open in Windows Terminal" from a directory or from the background of a directory, it starts Windows Terminal 1.4.3243.0. Is that the same issue?

At HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\ClassIndex\{9F156763-7844-4DC4-B2B1-901F640F5155}, there are two subkeys:

  • Microsoft.WindowsTerminal_1.4.3243.0_x64__8wekyb3d8bbwe
  • Microsoft.WindowsTerminalPreview_1.6.10272.0_x64__8wekyb3d8bbwe

At HKEY_CURRENT_USER\SOFTWARE\Classes\PackagedCom\Package, there are identically named subkeys, and a few others besides. Here, each subkey has a REG_DWORD default value that may indicate the order in which the apps were installed; Windows Terminal Preview has 19 and Windows Terminal has 20. If I change the Windows Terminal value to 2 and restart Explorer, then "Open in Windows Terminal" starts Windows Terminal Preview. I think it means Packaged COM prefers the package that was installed last.

@KalleOlaviNiemitalo commented on GitHub (Feb 3, 2021): I have Windows Terminal 1.4.3243.0 and Windows Terminal Preview 1.6.10272.0, and when I choose "Open in Windows Terminal" from a directory or from the background of a directory, it starts Windows Terminal 1.4.3243.0. Is that the same issue? At `HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\ClassIndex\{9F156763-7844-4DC4-B2B1-901F640F5155}`, there are two subkeys: * Microsoft.WindowsTerminal_1.4.3243.0_x64__8wekyb3d8bbwe * Microsoft.WindowsTerminalPreview_1.6.10272.0_x64__8wekyb3d8bbwe At `HKEY_CURRENT_USER\SOFTWARE\Classes\PackagedCom\Package`, there are identically named subkeys, and a few others besides. Here, each subkey has a REG_DWORD default value that may indicate the order in which the apps were installed; Windows Terminal Preview has 19 and Windows Terminal has 20. If I change the Windows Terminal value to 2 and restart Explorer, then "Open in Windows Terminal" starts Windows Terminal Preview. I think it means [Packaged COM](<https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/> "COM Server and OLE Document support for the Desktop Bridge - Windows Developer Blog") prefers the package that was installed last.
Author
Owner

@ghost commented on GitHub (Apr 14, 2021):

:tada:This issue was addressed in #9510, which has now been successfully released as Windows Terminal v1.7.1033.0.🎉

Handy links:

@ghost commented on GitHub (Apr 14, 2021): :tada:This issue was addressed in #9510, which has now been successfully released as `Windows Terminal v1.7.1033.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.7.1033.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Author
Owner

@ghost commented on GitHub (Apr 14, 2021):

:tada:This issue was addressed in #9510, which has now been successfully released as Windows Terminal Preview v1.8.1032.0.🎉

Handy links:

@ghost commented on GitHub (Apr 14, 2021): :tada:This issue was addressed in #9510, which has now been successfully released as `Windows Terminal Preview v1.8.1032.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.8.1032.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8917