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

Cannot find info on hosting terminal in another app. #6418

New Issue
Open
opened 2026-01-31 00:38:05 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 00:38:05 +00:00
Owner
Copy Link

Originally created by @sharpninja on GitHub (Feb 13, 2020).

Originally assigned to: @DHowett on GitHub.

We need documentation on hosting the console. Project templates would be very helpful.

Originally created by @sharpninja on GitHub (Feb 13, 2020). Originally assigned to: @DHowett on GitHub. We need documentation on hosting the console. Project templates would be very helpful.
claunia added the Issue-DocsProduct-MetaArea-TerminalControl labels 2026-01-31 00:38:06 +00:00
claunia commented 2026-01-31 00:38:07 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 13, 2020):

This is very well-documented on our docs.microsoft.com section

@DHowett-MSFT commented on GitHub (Feb 13, 2020): This is very well-documented [on our docs.microsoft.com section](https://docs.microsoft.com/en-us/windows/console/creating-a-pseudoconsole-session)
claunia commented 2026-01-31 00:38:07 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 13, 2020):

There's also samples in this repository.

@DHowett-MSFT commented on GitHub (Feb 13, 2020): There's also samples [in this repository](https://github.com/microsoft/terminal/tree/master/samples/ConPTY).
claunia commented 2026-01-31 00:38:07 +00:00
Author
Owner
Copy Link

@sharpninja commented on GitHub (Feb 13, 2020):

There are no samples or document for hosting in a UWP process, which has been promised for a long time. Please reopen.

@sharpninja commented on GitHub (Feb 13, 2020): There are no samples or document for hosting in a UWP process, which has been promised for a long time. Please reopen.
claunia commented 2026-01-31 00:38:08 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 13, 2020):

We haven’t promised documentation on that, because hosting an unconstrained application from a UWP context is currently impossible. This is why we didn’t build the terminal as a UWP. That’s just not something the platform supports.

@DHowett-MSFT commented on GitHub (Feb 13, 2020): We haven’t promised documentation on that, because hosting an unconstrained application from a UWP context is currently impossible. This is why we didn’t build the terminal as a UWP. That’s just not something the platform supports.
claunia commented 2026-01-31 00:38:08 +00:00
Author
Owner
Copy Link

@sharpninja commented on GitHub (Feb 13, 2020):

This is literally line 4, as a Priority 0 item:

Terminal's core will be hostable as a UWP (and perhaps WPF) Control so that apps can host/embed a high quality Terminal. This will satisfy a long-standing ask from many customers and partners for a hostable/embeddable Terminal Control.

source

From: Dustin L. Howett (MSFT) notifications@github.com
Sent: Thursday, February 13, 2020 4:11 PM
To: microsoft/terminal terminal@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Author author@noreply.github.com
Subject: Re: [microsoft/terminal] Cannot find info on hosting terminal in another app. (#4572)

We haven’t promised documentation on that, because hosting an unconstrained application from a UWP context is currently impossible. This is why we didn’t build the terminal as a UWP. That’s just not something the platform supports.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/terminal/issues/4572?email_source=notifications&email_token=AD3GCLE4BVNKY2PNGGCQBGTRCXARRA5CNFSM4KU25ZHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWZXCY#issuecomment-585997195, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLFVVFSAQIK2JFIT23TRCXARRANCNFSM4KU25ZHA.

@sharpninja commented on GitHub (Feb 13, 2020): This is literally line 4, as a Priority 0 item: > Terminal's core will be hostable as a UWP (and perhaps WPF) Control so that apps can host/embed a high quality Terminal. This will satisfy a long-standing ask from many customers and partners for a hostable/embeddable Terminal Control. [source](https://github.com/microsoft/terminal/blob/master/doc/terminal-v1-roadmap.md) ________________________________ From: Dustin L. Howett (MSFT) <notifications@github.com> Sent: Thursday, February 13, 2020 4:11 PM To: microsoft/terminal <terminal@noreply.github.com> Cc: The Sharp Ninja <ninja@thesharp.ninja>; Author <author@noreply.github.com> Subject: Re: [microsoft/terminal] Cannot find info on hosting terminal in another app. (#4572) We haven’t promised documentation on that, because hosting an unconstrained application from a UWP context is currently impossible. This is why we didn’t build the terminal as a UWP. That’s just not something the platform supports. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://github.com/microsoft/terminal/issues/4572?email_source=notifications&email_token=AD3GCLE4BVNKY2PNGGCQBGTRCXARRA5CNFSM4KU25ZHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWZXCY#issuecomment-585997195>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD3GCLFVVFSAQIK2JFIT23TRCXARRANCNFSM4KU25ZHA>.
claunia commented 2026-01-31 00:38:08 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 13, 2020):

Okay you're not wrong about that. That doc is maybe a little out of date, but I guess we did mention that publicly.

The way the terminal's architecture is designed, it's certainly possible to re-use the terminal control in other UWP projects. However, I think we've let the priority of that particular feature slip a bit as we approach 1.0. AS it currently stands, I don't think that we'll have the cycles to be able to officially support a nuget package or something for the terminal control in the 1.0 timeframe. I think it was more important for us to prepare for allowing arbitrary apps to host the control, and that we've most certainly done.

Thant being said, it'd definitely be possible to unofficially use the TerminalControl.dll and TerminalControl.winmd that's built from this project in other projects. I'm not saying you should do this. I'm saying you could.

@DHowett-MSFT is alluding to the fact that launching other processes from a UWP context is fraught with peril. Those perils is why we've chosen the Win32+Xaml Hosting model for the Terminal. That being said, you could totally add a terminal to a pure UWP application. Just be aware that it's a here be dragons path.

We probably should add documentation on this, but I'm going to toss it on the backlog, since I don't think we'll want to author documentation at this time while things are still changing pretty rapidly.

@zadjii-msft commented on GitHub (Feb 13, 2020): Okay you're not wrong about that. That doc is maybe a little out of date, but I guess we did mention that publicly. The way the terminal's architecture is designed, it's certainly _possible_ to re-use the terminal control in other UWP projects. However, I think we've let the priority of that particular feature slip a bit as we approach 1.0. AS it currently stands, I don't think that we'll have the cycles to be able to _officially_ support a nuget package or something for the terminal control in the 1.0 timeframe. I think it was more important for us to _prepare_ for allowing arbitrary apps to host the control, and that we've most certainly done. Thant being said, it'd definitely be possible to _unofficially_ use the `TerminalControl.dll` and `TerminalControl.winmd` that's built from this project in other projects. I'm not saying you _should_ do this. I'm saying you _could_. @DHowett-MSFT is alluding to the fact that launching other processes from a UWP context is fraught with peril. Those perils is why we've chosen the Win32+Xaml Hosting model for the Terminal. That being said, you could totally add a terminal to a pure UWP application. Just be aware that it's a _here be dragons_ path. We probably should add documentation on this, but I'm going to toss it on the backlog, since I don't think we'll want to author documentation at this time while things are still changing pretty rapidly.
claunia commented 2026-01-31 00:38:09 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 13, 2020):

Ah, sorry about that!

@DHowett-MSFT commented on GitHub (Feb 13, 2020): Ah, sorry about that!
claunia commented 2026-01-31 00:38:09 +00:00
Author
Owner
Copy Link

@sharpninja commented on GitHub (Feb 13, 2020):

Totally cool!

I am very happy to guinea pig this as I'm working on a project that literally is providing a programmer's "toolbox" that having an embedded terminal is a foundational requirement, and I started this project after months ago reading that quote and anxiously awaiting the release of the hostable console. I understand not wanting to post any formal docs yet, but if you could at least give me a rough set of steps to get a terminal hosted in a C# UWP app then I'd be greatly appreciative.

@sharpninja commented on GitHub (Feb 13, 2020): # Totally cool! I am very happy to _guinea pig this_ as I'm working on a project that literally is providing a programmer's "toolbox" that having an embedded terminal is a foundational requirement, and I started this project after months ago reading that quote and anxiously awaiting the release of the hostable console. I understand not wanting to post any formal docs yet, but if you could at least give me a rough set of steps to get a terminal hosted in a C# UWP app then I'd be greatly appreciative.
claunia commented 2026-01-31 00:38:10 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 14, 2020):

@sharpninja If you're willing to take instructions with no warranty whatsoever and do something that might simply break for no reason because we're not ready to ship it yet, read on...

And on and on

If you build Terminal, you'll get a bunch of interesting things in ./x64/Debug:

  • TerminalControl.dll and TerminalControl.winmd: These implement the terminal control; the winmd is how you'll import references to another project. This is easier with C#, actually, but I don't know how it's going to feel about activating classes from these DLLs.
  • resources.pri: Localizable resources from the entire terminal app and all of microsoft.ui.xaml (sorry: we can't split it finer than this right now; you might be able to grab a pri from x64/Debug/TerminalControl?)
  • TerminalSettings.dll and TerminalSettings.winmd: A single-class library that lets you construct an object that can be used to pass settings to a terminal.
  • TerminalConnection.dll and TerminalConnection.winmd: Contains the ITerminalConnection interface you'll need to conform to and a couple other classes. If you don't need the conpty, azure or telnet connections you should be able to get by with only the winmd? If you copy the dll, make sure to copy cpprest and telnetpp DLLs as well.

Know that you'll be going significantly off-road here.

Anyway, once you grab those things and integrate them into your own package, you should be able to host a Microsoft.Terminal.TerminalControl.TermControl (yes, that is a heck of a name) in your Xaml tree. It can't be constructed without an IControlSettings (TerminalSettings winmd) and an ITerminalConnection (TerminalConnection winmd).

There might be one or two .xbf files you need as well; if you see it failing to load SearchBoxControl, you'll want to make sure you copy that over too.

It's really not in a good place right now!

@DHowett-MSFT commented on GitHub (Feb 14, 2020): @sharpninja If you're willing to take instructions with _no warranty whatsoever_ and do something that might simply break for no reason because we're not ready to ship it yet, read on... <details> <summary>And on and on</summary> If you _build Terminal_, you'll get a bunch of interesting things in `./x64/Debug`: * `TerminalControl.dll` and `TerminalControl.winmd`: These implement the terminal control; the winmd is how you'll import references to another project. This is _easier_ with C#, actually, but I don't know how it's going to feel about activating classes from these DLLs. * `resources.pri`: Localizable resources from the entire terminal app and all of microsoft.ui.xaml (sorry: we can't split it finer than this right now; you might be able to grab a `pri` from x64/Debug/TerminalControl?) * `TerminalSettings.dll` and `TerminalSettings.winmd`: A single-class library that lets you construct an object that can be used to pass settings to a terminal. * `TerminalConnection.dll` and `TerminalConnection.winmd`: Contains the ITerminalConnection interface you'll need to conform to _and_ a couple other classes. If you don't need the conpty, azure or telnet connections you should be able to get by with only the winmd? If you copy the dll, make sure to copy `cpprest` and `telnetpp` DLLs as well. Know that you'll be going significantly off-road here. Anyway, once you grab those things and integrate them into your own package, you should be able to host a `Microsoft.Terminal.TerminalControl.TermControl` (yes, that is a heck of a name) in your Xaml tree. It can't be constructed without an `IControlSettings` (TerminalSettings winmd) and an `ITerminalConnection` (TerminalConnection winmd). There might be one or two .xbf files you need as well; if you see it failing to load SearchBoxControl, you'll want to make sure you copy that over too. It's really not in a good place right now! </details>
claunia commented 2026-01-31 00:38:10 +00:00
Author
Owner
Copy Link

@sharpninja commented on GitHub (Feb 14, 2020):

Thank you so much! I know what I’m doing this weekend.

@sharpninja commented on GitHub (Feb 14, 2020): Thank you so much! I know what I’m doing this weekend.
claunia commented 2026-01-31 00:38:10 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 14, 2020):

If you want to go significantly the other way on this, the WpfTerminalControl project will produce a nuget package with far fewer dependencies that'll work with WPF Xaml (yeah!) down to Windows 7ish. I know that's really outside the scope of UWP 😉

@DHowett-MSFT commented on GitHub (Feb 14, 2020): If you want to go significantly the _other_ way on this, the WpfTerminalControl project will produce a nuget package with far fewer dependencies that'll work with _WPF_ Xaml (yeah!) down to Windows 7ish. I know that's really outside the scope of UWP :wink:
claunia commented 2026-01-31 00:38:11 +00:00
Author
Owner
Copy Link

@RWeigelt commented on GitHub (May 21, 2020):

If you want to go significantly the other way on this, the WpfTerminalControl project will produce a nuget package with far fewer dependencies that'll work with WPF Xaml [...]

Where can I find more information about WpfTerminalControl and how to use it in my WPF application?

@RWeigelt commented on GitHub (May 21, 2020): > If you want to go significantly the _other_ way on this, the WpfTerminalControl project will produce a nuget package with far fewer dependencies that'll work with _WPF_ Xaml [...] Where can I find more information about WpfTerminalControl and how to use it in my WPF application?
claunia commented 2026-01-31 00:38:11 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 22, 2020):

Sorry -- it's undocumented for a reason. It's very much an act of trailblazing to get it going.

@DHowett commented on GitHub (May 22, 2020): Sorry -- it's undocumented for a reason. It's very much an act of trailblazing to get it going.
claunia commented 2026-01-31 00:38:11 +00:00
Author
Owner
Copy Link

@akasarto commented on GitHub (Jan 17, 2022):

Hey! If someone is still interested in this, I've been playing around with the available WpfTerminalControl and the simplest way I found to make this work is as follows:

  • Make sure the WPF app has the compiled PublicTerminalCore.dll available for DLLImport/PInvoke. I was able to achieve this by including the microsoft/terminal repository as a submodule of mine and creating a script called build-deps.cmd to compile only the necessary bits: /modules/ms-terminal/src/cascadia/PublicTerminalCore.
  • Add a reference to the submodule /src/cascadia/WpfTerminalControl project to your solution.
  • Implement the ITerminalConnection to handle user input.
  • On your WPF app, add a reference to the WpfTerminalControl project above and instantiate the user control TerminalControl.xaml, assigning your custom IterminalConnection implementation to it.

**Note that for the compilation script above to work, the Prerequisites from the microsoft/terminal must be met.

The implementation referred above can be found under the net5-refactor branch, here

For my use case, the result looks like this:

dTerm

@akasarto commented on GitHub (Jan 17, 2022): Hey! If someone is still interested in this, I've been playing around with the available [WpfTerminalControl](/microsoft/terminal/tree/main/src/cascadia/WpfTerminalControl) and the simplest way I found to make this work is as follows: - Make sure the WPF app has the compiled `PublicTerminalCore.dll` available for _DLLImport/PInvoke_. I was able to achieve this by including the _microsoft/terminal_ repository as a submodule of mine and creating a script called `build-deps.cmd` to compile only the necessary bits: `/modules/ms-terminal/src/cascadia/PublicTerminalCore`. - Add a reference to the submodule `/src/cascadia/WpfTerminalControl` project to your solution. - Implement the `ITerminalConnection` to handle user input. - On your WPF app, add a reference to the `WpfTerminalControl` project above and instantiate the user control `TerminalControl.xaml`, assigning your custom `IterminalConnection` implementation to it. **Note that for the compilation script above to work, the `Prerequisites` from the [microsoft/terminal](/microsoft/terminal) must be met. The implementation referred above can be found under the `net5-refactor` branch, [here](https://github.com/akasarto/d-term/tree/net5-refactor) For my use case, the result looks like this: ![dTerm](/akasarto/d-term/blob/net5-refactor/media/dTerm.png?raw=true "dTerm")
claunia commented 2026-01-31 00:38:11 +00:00
Author
Owner
Copy Link

@Crypties commented on GitHub (Apr 14, 2023):

It's really not in a good place right now!

About 3 years later. Is it in a good place now?

@Crypties commented on GitHub (Apr 14, 2023): > It's really not in a good place right now! About 3 years later. Is it in a good place now?
claunia commented 2026-01-31 00:38:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 20, 2023):

Not really. This unfortunately hasn't really bubbled up to the top of our list of priorities yet.

  • The WPF control is technically hostable in another app, but not in a productized sense. See #15053. You could surely follow that path, with the caveat that the entire interface is subject to change.
  • Speaking of productization, we're mostly tracking that in #6999.
  • We really want to refine the whole HwndTerminal / TerminalCore / ControlCore/Interactivity story. There's a lot of duplicated work there, and we could surely just replace one with the other.
@zadjii-msft commented on GitHub (Apr 20, 2023): Not really. This unfortunately hasn't really bubbled up to the top of our list of priorities yet. * The WPF control is _technically_ hostable in another app, but not in a productized sense. See #15053. You could surely follow that path, with the caveat that _the entire interface is subject to change_. * Speaking of productization, we're mostly tracking that in #6999. * We really want to refine the whole HwndTerminal / TerminalCore / ControlCore/Interactivity story. There's a lot of duplicated work there, and we could surely just replace one with the other.
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-TerminalControl Issue-Docs Product-Meta
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#6418
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?