starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

VS devshell generator should prefer using powershell core if available #15402

New Issue
Open
opened 2026-01-31 04:37:37 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 04:37:37 +00:00
Owner
Copy Link

Originally created by @LuanVSO on GitHub (Sep 30, 2021).

moved from https://github.com/microsoft/terminal/pull/11326#issuecomment-930690887

Description of the new feature/enhancement

use pwsh for the devshell command on the visual studio generators

Originally created by @LuanVSO on GitHub (Sep 30, 2021). moved from https://github.com/microsoft/terminal/pull/11326#issuecomment-930690887 # Description of the new feature/enhancement use pwsh for the devshell command on the visual studio generators
claunia added the Help WantedArea-SettingsIssue-TaskProduct-Terminal labels 2026-01-31 04:37:37 +00:00
claunia commented 2026-01-31 04:37:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 30, 2021):

Now this one's tricky - we can be sure that powershell.exe is installed. We can't be sure that a version of pwsh.exe is. We'd have to have the Visual Studio generators rely on the same powershell core detection as the powershell core generator. I don't really want to have a hard dependency from one generator on the output of another generator - they should be able to exist independently. We can re-use the code, but let's not plumb the literal Profiles from one generator to the next.

I'm sure @heaths will have thoughts on the matter.

@zadjii-msft commented on GitHub (Sep 30, 2021): Now this one's tricky - we can be sure that `powershell.exe` is installed. We _can't_ be sure that a version of `pwsh.exe` is. We'd have to have the Visual Studio generators rely on the same powershell core detection as the powershell core generator. I don't really want to have a hard dependency from one generator on the output of another generator - they should be able to exist independently. We can re-use the code, but let's not plumb the literal `Profile`s from one generator to the next. I'm sure @heaths will have thoughts on the matter.
claunia commented 2026-01-31 04:37:38 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Sep 30, 2021):

The shortcuts installed by Visual Studio use Windows PowerShell. Some cmdlets on Windows they may rely on e.g. AppX also only work on Windows PowerShell. I don't think it'd be appropriate to assume support for Dev Shell on PowerShell (Core). Users could configure this otherwise, but I don't think Terminal should do so automatically, thus implying support where there is none.

@heaths commented on GitHub (Sep 30, 2021): The shortcuts installed by Visual Studio use Windows PowerShell. Some cmdlets on Windows they may rely on e.g. AppX also only work on Windows PowerShell. I don't think it'd be appropriate to assume support for Dev Shell on PowerShell (Core). Users could configure this otherwise, but I don't think Terminal should do so automatically, thus implying support where there is none.
claunia commented 2026-01-31 04:37:38 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Sep 30, 2021):

That said, if we did want to support this - and we'd need to talk with the VC team to be sure that's okay (I'll start an internal thread) - we could refactor out the powershell/pwsh look-up and use that; however, I do worry about the overall startup perf of WT. Perhaps we can cache (statics or whatever) that lookup. So we wouldn't be depending directly on the PowerShell generator, though the brunt of it.

It does raise another issue in my head, though, and perhaps worth of another issue: WT startup perf gets worse with each new generator. Should we have a way to turn them off (do we read the config early enough?) or even run them every X days or something? Or is the thought here (and telemetry to back it up) most people start WT once in a while and just let it run (I do, but that's anecdotal).

@heaths commented on GitHub (Sep 30, 2021): That said, if we did want to support this - and we'd need to talk with the VC team to be sure that's okay (I'll start an internal thread) - we could refactor out the powershell/pwsh look-up and use that; however, I do worry about the overall startup perf of WT. Perhaps we can cache (statics or whatever) that lookup. So we wouldn't be depending directly on the PowerShell generator, though the brunt of it. It does raise another issue in my head, though, and perhaps worth of another issue: WT startup perf gets worse with each new generator. Should we have a way to turn them off (do we read the config early enough?) or even run them every X days or something? Or is the thought here (and telemetry to back it up) most people start WT once in a while and just let it run (I do, but that's anecdotal).
claunia commented 2026-01-31 04:37:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 30, 2021):

Should we have a way to turn them off (do we read the config early enough?

We do, disabledProfileSources. They only run when a window is started (or the settings are hot-reloaded)

@zadjii-msft commented on GitHub (Sep 30, 2021): > Should we have a way to turn them off (do we read the config early enough? We do, `disabledProfileSources`. They only run when a window is started (or the settings are hot-reloaded)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Help Wanted Issue-Task Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15402
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?