maxmustermann
/
terminal
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
terminal/OpenConsole.sln

1564 lines
118 KiB
Plaintext
Raw Normal View History

Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00

Microsoft Visual Studio Solution File, Format Version 12.00
Apply a GDI region to the top level Island window to allow dragging with a single Island (#929) * Use a region to cut off the dragable region * Use proper measurements for the draggable area * Working better, paint works most of the time * Fix a bug where paint is incomplete when double clicking the dragbar * Remove old fork on XamlApplication * Upgrade to XamlApp preview6.2 * Add Microsoft.VCRTForwarders to make it easy to dogfood Co-Authored-By: Michael Niksa <miniksa@microsoft.com> Co-Authored-By: Mike Griese <migrie@microsoft.com>
2019-06-25 22:06:11 +02:00
# Visual Studio Version 16
VisualStudioVersion = 16.0.29001.49
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
MinimumVisualStudioVersion = 10.0.40219.1
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Terminal", "Terminal", "{59840756-302F-44DF-AA47-441A9D673202}"
EndProject
Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "CascadiaPackage", "src\cascadia\CascadiaPackage\CascadiaPackage.wapproj", "{CA5CAD1A-224A-4171-B13A-F16E576FDD12}"
EndProject
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.EXE", "src\host\exe\Host.EXE.vcxproj", "{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}"
ProjectSection(ProjectDependencies) = postProject
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "PropertiesLibrary", "src\propslib\propslib.vcxproj", "{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "_Dependencies", "_Dependencies", "{81C352DB-1818-45B7-A284-18E259F1CC87}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "wil", "wil", "{4C8E6BB0-4713-4ADB-BD04-81628ECEAF20}"
ProjectSection(SolutionItems) = preProject
dep\wil\include\wil\common.h = dep\wil\include\wil\common.h
dep\wil\include\wil\filesystem.h = dep\wil\include\wil\filesystem.h
dep\wil\include\wil\functional.h = dep\wil\include\wil\functional.h
dep\wil\include\wil\registry.h = dep\wil\include\wil\registry.h
dep\wil\include\wil\resource.h = dep\wil\include\wil\resource.h
dep\wil\include\wil\result.h = dep\wil\include\wil\result.h
dep\wil\include\wil\resultmacros.h = dep\wil\include\wil\resultmacros.h
dep\wil\include\wil\stl.h = dep\wil\include\wil\stl.h
dep\wil\include\wil\win32helpers.h = dep\wil\include\wil\win32helpers.h
dep\wil\include\wil\wistd_functional.h = dep\wil\include\wil\wistd_functional.h
dep\wil\include\wil\wistd_memory.h = dep\wil\include\wil\wistd_memory.h
dep\wil\include\wil\wistd_type_traits.h = dep\wil\include\wil\wistd_type_traits.h
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Console", "Console", "{D57841D1-8294-4F2B-BB8B-D2A35738DECD}"
ProjectSection(SolutionItems) = preProject
dep\Console\winconp.h = dep\Console\winconp.h
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TextServicesFramework", "src\tsf\tsf.vcxproj", "{2FD12FBB-1DDB-46D8-B818-1023C624CACA}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser", "src\terminal\parser\lib\parser.vcxproj", "{3AE13314-1939-4DFA-9C14-38CA0834050C}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAdapter", "src\terminal\adapter\lib\adapter.vcxproj", "{DCF55140-EF6A-4736-A403-957E4F7430BB}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalInput", "src\terminal\input\lib\terminalinput.vcxproj", "{1CF55140-EF6A-4736-A403-957E4F7430BB}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererBase", "src\renderer\base\lib\base.vcxproj", "{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererGdi", "src\renderer\gdi\lib\gdi.vcxproj", "{1C959542-BAC2-4E55-9A6D-13251914CBB9}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host", "src\host\lib\hostlib.vcxproj", "{06EC74CB-9A12-429C-B551-8562EC954746}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.unittest", "src\host\ut_lib\host.unittest.vcxproj", "{06EC74CB-9A12-429C-B551-8562EC954747}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.Tests.Unit", "src\host\ut_host\Host.UnitTests.vcxproj", "{531C23E7-4B76-4C08-8AAD-04164CB628C9}"
ProjectSection(ProjectDependencies) = postProject
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
{06EC74CB-9A12-429C-B551-8562EC954747} = {06EC74CB-9A12-429C-B551-8562EC954747}
EndProjectSection
EndProject
Turn on Text Buffer unit tests in Azure DevOps CI build (#1057) * rename TextBuffer.UnitTests.dll -> TextBuffer.Unit.Tests.dll * renamed the project file as well
2019-05-30 04:51:17 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TextBuffer.Unit.Tests", "src\buffer\out\ut_textbuffer\TextBuffer.Unit.Tests.vcxproj", "{531C23E7-4B76-4C08-8BBD-04164CB628C9}"
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
ProjectSection(ProjectDependencies) = postProject
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.Tests.Feature", "src\host\ft_host\Host.FeatureTests.vcxproj", "{8CDB8850-7484-4EC7-B45B-181F85B2EE54}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
{FC802440-AD6A-4919-8F2C-7701F2B38D79} = {FC802440-AD6A-4919-8F2C-7701F2B38D79}
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser.UnitTests", "src\terminal\parser\ut_parser\Parser.UnitTests.vcxproj", "{12144E07-FE63-4D33-9231-748B8D8C3792}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAdapter.UnitTests", "src\terminal\adapter\ut_adapter\Adapter.UnitTests.vcxproj", "{6AF01638-84CF-4B65-9870-484DFFCAC772}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser.Fuzzer", "src\terminal\parser\ft_fuzzer\VTCommandFuzzer.vcxproj", "{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser.FuzzWrapper", "src\terminal\parser\ft_fuzzwrapper\FuzzWrapper.vcxproj", "{F210A4AE-E02A-4BFC-80BB-F50A672FE763}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Propsheet.DLL", "src\propsheet\propsheet.vcxproj", "{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "_Build Common", "_Build Common", "{04170EEF-983A-4195-BFEF-2321E5E38A1E}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Server", "src\server\lib\server.vcxproj", "{18D09A24-8240-42D6-8CB6-236EEE820262}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Host.Tests.UIA", "src\host\ft_uia\Host.Tests.UIA.csproj", "{C17E1BF3-9D34-4779-9458-A8EF98CC5662}"
ProjectSection(ProjectDependencies) = postProject
{099193A0-1E43-4BBC-BA7F-7B351E1342DF} = {099193A0-1E43-4BBC-BA7F-7B351E1342DF}
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB} = {C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
EndProjectSection
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "VTApp", "src\tools\vtapp\VTApp.csproj", "{099193A0-1E43-4BBC-BA7F-7B351E1342DF}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "_Tools", "_Tools", "{A10C4720-DCA4-4640-9749-67F4314F527C}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Nihilist", "src\tools\nihilist\Nihilist.vcxproj", "{FC802440-AD6A-4919-8F2C-7701F2B38D79}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "FontList", "src\tools\fontlist\FontList.vcxproj", "{919544AC-D39B-463F-8414-3C3C67CF727C}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Scratch", "src\tools\scratch\Scratch.vcxproj", "{ED82003F-FC5D-4E94-8B36-F480018ED064}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InteractivityWin32", "src\interactivity\win32\lib\win32.LIB.vcxproj", "{06EC74CB-9A12-429C-B551-8532EC964726}"
ProjectSection(ProjectDependencies) = postProject
{1C959542-BAC2-4E55-9A6D-13251914CBB9} = {1C959542-BAC2-4E55-9A6D-13251914CBB9}
{990F2657-8580-4828-943F-5DD657D11842} = {990F2657-8580-4828-943F-5DD657D11842}
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F} = {AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "buffersize", "src\tools\buffersize\buffersize.vcxproj", "{ED82003F-FC5D-4E94-8B47-F480018ED064}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InteractivityBase", "src\interactivity\base\lib\InteractivityBase.vcxproj", "{06EC74CB-9A12-429C-B551-8562EC964846}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Interactivity.Win32.Tests.Unit", "src\interactivity\win32\ut_interactivity_win32\Interactivity.Win32.UnitTests.vcxproj", "{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}"
ProjectSection(ProjectDependencies) = postProject
{990F2657-8580-4828-943F-5DD657D11842} = {990F2657-8580-4828-943F-5DD657D11842}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "CloseTest", "src\tools\closetest\CloseTest.vcxproj", "{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererVt", "src\renderer\vt\lib\vt.vcxproj", "{990F2657-8580-4828-943F-5DD657D11842}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "VtPipeTerm", "src\tools\vtpipeterm\VtPipeTerm.vcxproj", "{814DBDDE-894E-4327-A6E1-740504850098}"
The InputStateMachine should dispatch Intermediate characters (#1267) The OutputStateMachine needs to collect "Intermediate" characters to be able to call [`Designate G0 Character Set`](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Controls-beginning-with-ESC) (as well as other sequences we don't yet support). However, the InputStateMachine used by conpty to process input should _not_ collect these characters. The input engine uses `\x1b` as an indicator that a key was pressed with `Alt`. For keys like `/`, we want to dispatch the key immediately, instead of collecting it and leaving us in the Escape state.
2019-06-14 21:48:12 +02:00
ProjectSection(ProjectDependencies) = postProject
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
EndProjectSection
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ConEchoKey", "src\tools\echokey\ConEchoKey.vcxproj", "{814CBEEE-894E-4327-A6E1-740504850098}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Types", "src\types\lib\types.vcxproj", "{18D09A24-8240-42D6-8CB6-236EEE820263}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererVt.unittest", "src\renderer\vt\ut_lib\vt.unittest.vcxproj", "{990F2657-8580-4828-943F-5DD657D11843}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "BufferOut", "src\buffer\out\lib\bufferout.vcxproj", "{0CF235BD-2DA0-407E-90EE-C467E8BBC714}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererDx", "src\renderer\dx\lib\dx.vcxproj", "{48D21369-3D7B-4431-9967-24E81292CF62}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalConnection", "src\cascadia\TerminalConnection\TerminalConnection.vcxproj", "{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalCore", "src\cascadia\TerminalCore\lib\TerminalCore-lib.vcxproj", "{CA5CAD1A-ABCD-429C-B551-8562EC954746}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalControl", "src\cascadia\TerminalControl\TerminalControl.vcxproj", "{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {CA5CAD1A-ABCD-429C-B551-8562EC954746}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
{1CF55140-EF6A-4736-A403-957E4F7430BB} = {1CF55140-EF6A-4736-A403-957E4F7430BB}
Hey look the TermControl needs to depend on the UIA renderer (#3983) We unintentionally broke the build in #2930. If you're building the entire solution, then you won't have any problems, because the `UiaRenderer` project will get built before the `TerminalControl`. However, if you're like me and you only really build the solution one project at a time, you'll find that building `TerminalControl` won't build `UiaRenderer` automagically. This fixes that. s/o to @Rrogntudju for catching this
2019-12-17 19:16:26 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63} = {48D21369-3D7B-4431-9967-24E81292CF63}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminal", "src\cascadia\WindowsTerminal\WindowsTerminal.vcxproj", "{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12} = {CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}
{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {CA5CAD1A-ABCD-429C-B551-8562EC954746}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalApp", "src\cascadia\TerminalApp\TerminalApp.vcxproj", "{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}"
ProjectSection(ProjectDependencies) = postProject
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalSettings", "src\cascadia\TerminalSettings\TerminalSettings.vcxproj", "{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_TerminalCore", "src\cascadia\UnitTests_TerminalCore\UnitTests.vcxproj", "{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}"
Fix the `UnitTests_TerminalCore`'s dependency on `RendererGdi` (#4319) ## Summary of the Pull Request In #4213 I added a dependency to the `UnitTests_TerminalCore` project on basically all of conhost. This _worked on my machine_, but it's consistently not working on other machines. This should fix those issues. ## References ## PR Checklist * [x] Closes #4285 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed Made a fresh clone and built it.
2020-01-22 22:30:53 +01:00
ProjectSection(ProjectDependencies) = postProject
{06EC74CB-9A12-429C-B551-8562EC954747} = {06EC74CB-9A12-429C-B551-8562EC954747}
EndProjectSection
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Internal", "src\internal\internal.vcxproj", "{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "gsl", "gsl", "{16376381-CE22-42BE-B667-C6B35007008D}"
ProjectSection(SolutionItems) = preProject
dep\gsl\include\gsl\gsl = dep\gsl\include\gsl\gsl
dep\gsl\include\gsl\gsl_algorithm = dep\gsl\include\gsl\gsl_algorithm
dep\gsl\include\gsl\gsl_assert = dep\gsl\include\gsl\gsl_assert
dep\gsl\include\gsl\gsl_byte = dep\gsl\include\gsl\gsl_byte
dep\gsl\include\gsl\gsl_util = dep\gsl\include\gsl\gsl_util
dep\gsl\include\gsl\multi_span = dep\gsl\include\gsl\multi_span
dep\gsl\include\gsl\pointers = dep\gsl\include\gsl\pointers
dep\gsl\include\gsl\span = dep\gsl\include\gsl\span
dep\gsl\include\gsl\string_span = dep\gsl\include\gsl\string_span
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Virtual Terminal", "Virtual Terminal", "{F1995847-4AE5-479A-BBAF-382E51A63532}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Rendering", "Rendering", "{05500DEF-2294-41E3-AF9A-24E580B82836}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Conhost", "Conhost", "{E8F24881-5E37-4362-B191-A3BA0ED7F4EB}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Buffer", "Buffer", "{1E4A062E-293B-4817-B20D-BF16B979E350}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Shared", "Shared", "{89CDCC5C-9F53-4054-97A4-639D99F169CD}"
EndProject
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Types.Unit.Tests", "src\types\ut_types\Types.Unit.Tests.vcxproj", "{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}"
EndProject
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "PublicTerminalCore", "src\cascadia\PublicTerminalCore\PublicTerminalCore.vcxproj", "{84848BFA-931D-42CE-9ADF-01EE54DE7890}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalControl", "src\cascadia\WpfTerminalControl\WpfTerminalControl.csproj", "{376FE273-6B84-4EB5-8B30-8DE9D21B022C}"
EndProject
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_TerminalApp", "src\cascadia\ut_app\TerminalApp.UnitTests.vcxproj", "{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAppLib", "src\cascadia\TerminalApp\lib\TerminalAppLib.vcxproj", "{CA5CAD1A-9A12-429C-B551-8562EC954746}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
EndProjectSection
EndProject
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "LocalTests_TerminalApp", "src\cascadia\LocalTests_TerminalApp\TerminalApp.LocalTests.vcxproj", "{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
EndProjectSection
EndProject
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererUia", "src\renderer\uia\lib\uia.vcxproj", "{48D21369-3D7B-4431-9967-24E81292CF63}"
EndProject
Introduce a WinRT utils library and "checked resources" (#3350) This commit introduces a C++/WinRT utility library and moves ScopedResourceLoader into it. I decided to get uppity and introduce something I like to call "checked resources." The idea is that every resource reference from a library is knowable at compile time, and we should be able to statically ensure that all resources exist. This is a system that lets us immediately failfast (on launch) when a library makes a static reference to a resource that doesn't exist at runtime. It exposes two new (preprocessor) APIs: * `RS_(wchar_t)`: loads a localizable string resource by name. * `USES_RESOURCE(wchar_t)`: marks a resource key as used, but is intended for loading images or passing static resource keys as parameters to functions that will look them up later. Resource checking relies on diligent use of `USES_RESOURCE()` and `RS_()` (which uses `USES_RESOURCE`), but can make sure we don't ship something that'll blow up at runtime. It works like this: **IN DEBUG MODE** - All resource names referenced through `USES_RESOURCE()` are emitted alongside their referencing filenames and line numbers into a static section of the binary. That section is named `.util$res$m`. - We emit two sentinel values into two different sections, `.util$res$a` and `.util$res$z`. - The linker sorts all sections alphabetically before crushing them together into the final binary. - When we first construct a library's scoped resource loader, we iterate over every resource reference between `$a` and `$z` and check residency. **IN RELEASE MODE** - All checked resource code is compiled out. Fixes #2146. Macros are the only way to do something this cool, incidentally. ## Validation Steps Performed Made references to a bunch of bad resources, tried to break it a lot. It looks like this when it fails: ### App.cpp ``` 36 static const std::array<std::wstring_view, 2> settingsLoadErrorsLabels { 37 USES_RESOURCE(L"NoProfilesText"), 38 USES_RESOURCE(L"AllProfilesHiddenText_HA_JUST_KIDDING") 39 }; ``` ``` WinRTUtils\LibraryResources.cpp(68)\TerminalApp.dll: FailFast(1) tid(1034) 8000FFFF Catastrophic failure Msg:[Resource AllProfilesHiddenText_HA_JUST_KIDDING not found in scope TerminalApp/Resources (App.cpp:38)] [EnsureAllResourcesArePresent] ```
2019-11-01 23:47:05 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WinRTUtils", "src\cascadia\WinRTUtils\WinRTUtils.vcxproj", "{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}"
EndProject
Introduce a Universal package for Windows Terminal (#3236) This PR creates a Universal entrypoint for the Windows Terminal solution in search of our goals to run everywhere, on all Windows platforms. The Universal entrypoint is relatively straightforward and mostly just invokes the App without any of the other islands and win32 boilerplate required for the centennial route. The Universal project is also its own packaging project all in one and will emit a relevant APPX. A few things were required to make this work correctly: * Vcxitems reuse of resources (and link instructions on all of them for proper pkg layout) * Move all Terminal project CRT usages to the app ones (and ensure forwarders are only Nugetted to the Centennial package to not pollute the Universal one) * Fix/delay dependencies in `TerminalApp` that are not available in the core platform (or don't have an appropriate existing platform forwarder... do a loader snaps check) * vcpkg needs updating for the Azure connection parser * font fallbacks because Consolas isn't necessarily there * fallbacks because there are environments without a window handle Some of those happened in other small PRs in the past week or two. They were relevant to this. Note, this isn't *useful* as such yet. You can run the Terminal in this context and even get some of the shells to work. But they don't do a whole lot yet. Scoping which shells appear in the profiles list and only offering those that contextually make sense is future work. * Break everything out of App except the base initialization for XAML. AppLogic is the new home. * deduplicate logics by always using the app one (since it has to be there to support universal launch). * apparently that was too many cross-boundary calls and we can cache it because winrt objects are magic. * Put UWP project into solution. * tabs in titlebar needs disabling from uwp context as the non-client is way different. This adds a method to signal that to logic and apply the setting override. * Change to use App CRT in preparation for universal. * Try to make project build again by setting winconpty to static lib so it'll use the CRT inside TerminalConnection (or its other consumers) instead of linking its own. * Remove test for conpty dll, it's a lib now. Add additional commentary on how CRT linking works for future reference. I'm sure this will come up again. * This fixes the build error. * use the _apiset variant until proven otherwise to match the existing one. * Merge branch 'master' into dev/miniksa/uwp3 * recorrect spacing in cppwinrt.build.pre.props * Add multiple additional fonts to fallback to. Also, guard for invalid window handle on title update. * Remove ARMs from solution. * Share items resources between centennial and universal project. * cleanup resources and split manifest for dev/release builds. * Rev entire solution to latest Toolkit (6.0.0 stable release). * shorten the items file using include patterns * cleanup this filters file a bit. * Fix C26445 by using string_view as value, not ref. Don't build Universal in Audit because we're not auditing app yet. * some PR feedback. document losing the pointer. get rid of 16.3.9 workarounds. improve consistency of variable decl in applogic.h * Make dev phone product ID not match prod phone ID. Fix universal package identity to match proposed license information.
2019-11-26 01:30:45 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminalUniversal", "src\cascadia\WindowsTerminalUniversal\WindowsTerminalUniversal.vcxproj", "{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}"
EndProject
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.LIB", "src\winconpty\lib\winconptylib.vcxproj", "{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.DLL", "src\winconpty\dll\winconptydll.vcxproj", "{A22EC5F6-7851-4B88-AC52-47249D437A52}"
EndProject
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TestHostApp", "src\cascadia\LocalTests_TerminalApp\TestHostApp\TestHostApp.vcxproj", "{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506} = {CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Tests", "Tests", "{BDB237B6-1D1D-400F-84CC-40A58FA59C8E}"
EndProject
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "til.unit.tests", "src\til\ut_til\til.unit.tests.vcxproj", "{767268EE-174A-46FE-96F0-EEE698A1BBC9}"
EndProject
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "U8U16Test", "src\tools\U8U16Test\U8U16Test.vcxproj", "{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}"
EndProject
Move tests to invoke `te.exe` directly instead of using VSTest runner (#4490) Moves the tests from using the `vstest.console.exe` route to just using `te.exe`. PROs: - `te.exe` is significantly faster for running tests because the TAEF/VSTest adapter isn't great. - Running through `te.exe` is closer to what our developers are doing on their dev boxes - `te.exe` is how they run in the Windows gates. - `te.exe` doesn't seem to have the sporadic `0x6` error code thrown during the tests where somehow the console handles get lost - `te.exe` doesn't seem to repro the other intermittent issues that we have been having that are inscrutable. - Fewer processes in the tree (te is running anyway under `vstest.console.exe`, just indirected a lot - The log outputs scroll live with all our logging messages instead of suppressing everything until there's a failure - The log output is actually in the order things are happening versus vstest. CONs: - No more code coverage. - No more test records in the ADO build/test panel. - Tests really won't work inside Visual Studio at all. - The log files are really big now - Testing is not a test task anymore, just another script. Refuting each CON: - We didn't read the code coverage numbers - We didn't look at the ADO test panel results or build-over-build velocities - Tests didn't really work inside Visual Studio anyway unless you did the right incantations under the full moon. - We could tone down the logging if we wanted at either the te.exe execution time (with a switch) or by declaring properties in the tests/classes/modules that are very verbose to not log unless it fails. - I don't think anyone cares how they get run as long as they do.
2020-02-10 20:14:06 +01:00
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Common Props", "Common Props", "{53DD5520-E64C-4C06-B472-7CE62CA539C9}"
ProjectSection(SolutionItems) = preProject
src\common.build.post.props = src\common.build.post.props
src\common.build.pre.props = src\common.build.pre.props
src\common.build.tests.props = src\common.build.tests.props
common.openconsole.props = common.openconsole.props
src\cppwinrt.build.post.props = src\cppwinrt.build.post.props
src\cppwinrt.build.pre.props = src\cppwinrt.build.pre.props
src\wap-common.build.post.props = src\wap-common.build.post.props
src\wap-common.build.pre.props = src\wap-common.build.pre.props
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "YAML", "YAML", "{6B5A44ED-918D-4747-BFB1-2472A1FCA173}"
ProjectSection(SolutionItems) = preProject
build\pipelines\templates\build-console-audit-job.yml = build\pipelines\templates\build-console-audit-job.yml
build\pipelines\templates\build-console-ci.yml = build\pipelines\templates\build-console-ci.yml
build\pipelines\templates\build-console-int.yml = build\pipelines\templates\build-console-int.yml
build\pipelines\templates\build-console-steps.yml = build\pipelines\templates\build-console-steps.yml
build\pipelines\templates\check-formatting.yml = build\pipelines\templates\check-formatting.yml
build\pipelines\ci.yml = build\pipelines\ci.yml
build\pipelines\templates\release-sign-and-bundle.yml = build\pipelines\templates\release-sign-and-bundle.yml
build\pipelines\release.yml = build\pipelines\release.yml
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Scripts", "Scripts", "{D3EF7B96-CD5E-47C9-B9A9-136259563033}"
ProjectSection(SolutionItems) = preProject
build\scripts\Create-AppxBundle.ps1 = build\scripts\Create-AppxBundle.ps1
build\scripts\Index-Pdbs.ps1 = build\scripts\Index-Pdbs.ps1
build\scripts\Invoke-FormattingCheck.ps1 = build\scripts\Invoke-FormattingCheck.ps1
build\scripts\Run-Tests.ps1 = build\scripts\Run-Tests.ps1
build\scripts\Test-WindowsTerminalPackage.ps1 = build\scripts\Test-WindowsTerminalPackage.ps1
EndProjectSection
EndProject
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Dx.Unit.Tests", "src\renderer\dx\ut_dx\Dx.Unit.Tests.vcxproj", "{95B136F9-B238-490C-A7C5-5843C1FECAC4}"
EndProject
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.Tests.Feature", "src\winconpty\ft_pty\winconpty.FeatureTests.vcxproj", "{024052DE-83FB-4653-AEA4-90790D29D5BD}"
EndProject
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAzBridge", "src\cascadia\TerminalAzBridge\TerminalAzBridge.vcxproj", "{067F0A06-FCB7-472C-96E9-B03B54E8E18D}"
EndProject
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
AuditMode|Any CPU = AuditMode|Any CPU
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
AuditMode|ARM64 = AuditMode|ARM64
AuditMode|x64 = AuditMode|x64
AuditMode|x86 = AuditMode|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
Debug|Any CPU = Debug|Any CPU
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Debug|ARM64 = Debug|ARM64
Debug|x64 = Debug|x64
Debug|x86 = Debug|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
Release|Any CPU = Release|Any CPU
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Release|ARM64 = Release|ARM64
Release|x64 = Release|x64
Release|x86 = Release|x86
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|Any CPU.ActiveCfg = Debug|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x86.ActiveCfg = Release|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|Any CPU.ActiveCfg = Debug|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Deploy.0 = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Deploy.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Build.0 = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Deploy.0 = Debug|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|Any CPU.ActiveCfg = Release|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Deploy.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Deploy.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.ActiveCfg = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Build.0 = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Deploy.0 = Release|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.ActiveCfg = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.Build.0 = Debug|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.ActiveCfg = Debug|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.Build.0 = Debug|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.ActiveCfg = Debug|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.ActiveCfg = Release|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.Build.0 = Release|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.ActiveCfg = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.Build.0 = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.ActiveCfg = Release|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x64.ActiveCfg = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|ARM64.ActiveCfg = Debug|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|ARM64.Build.0 = Debug|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x64.ActiveCfg = Debug|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x64.Build.0 = Debug|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x86.ActiveCfg = Debug|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|ARM64.ActiveCfg = Release|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|ARM64.Build.0 = Release|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x64.ActiveCfg = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x64.Build.0 = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x86.ActiveCfg = Release|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x64.ActiveCfg = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|ARM64.ActiveCfg = Debug|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|ARM64.Build.0 = Debug|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x64.ActiveCfg = Debug|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x64.Build.0 = Debug|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x86.ActiveCfg = Debug|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|ARM64.ActiveCfg = Release|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|ARM64.Build.0 = Release|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x64.ActiveCfg = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x64.Build.0 = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x86.ActiveCfg = Release|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|ARM64.ActiveCfg = Release|ARM64
Apply audit mode to TerminalInput/Adapter/Parser libraries (#4005) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request - Enables auditing of Virtual Terminal libraries (input, adapter, parser) <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor * [x] Closes #3957 <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 15:25:21 +01:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x64.ActiveCfg = AuditMode|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|ARM64.Build.0 = Debug|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x64.ActiveCfg = Debug|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x64.Build.0 = Debug|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x86.ActiveCfg = Debug|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|ARM64.ActiveCfg = Release|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|ARM64.Build.0 = Release|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x64.ActiveCfg = Release|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x64.Build.0 = Release|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x86.ActiveCfg = Release|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
Apply audit mode to TerminalInput/Adapter/Parser libraries (#4005) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request - Enables auditing of Virtual Terminal libraries (input, adapter, parser) <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor * [x] Closes #3957 <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 15:25:21 +01:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.ActiveCfg = AuditMode|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.Build.0 = Debug|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.ActiveCfg = Debug|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.Build.0 = Debug|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.ActiveCfg = Debug|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.ActiveCfg = Release|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.Build.0 = Release|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.ActiveCfg = Release|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.Build.0 = Release|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.ActiveCfg = Release|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
Apply audit mode to TerminalInput/Adapter/Parser libraries (#4005) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request - Enables auditing of Virtual Terminal libraries (input, adapter, parser) <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor * [x] Closes #3957 <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 15:25:21 +01:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.ActiveCfg = AuditMode|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.Build.0 = Debug|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.ActiveCfg = Debug|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.Build.0 = Debug|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.ActiveCfg = Debug|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.ActiveCfg = Release|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.Build.0 = Release|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.ActiveCfg = Release|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.Build.0 = Release|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.ActiveCfg = Release|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x64.ActiveCfg = Release|x64
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x64.Build.0 = Release|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|ARM64.ActiveCfg = Debug|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|ARM64.Build.0 = Debug|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x64.ActiveCfg = Debug|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x64.Build.0 = Debug|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x86.ActiveCfg = Debug|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|ARM64.ActiveCfg = Release|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|ARM64.Build.0 = Release|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x64.ActiveCfg = Release|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x64.Build.0 = Release|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x86.ActiveCfg = Release|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x64.ActiveCfg = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|ARM64.Build.0 = Debug|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x64.ActiveCfg = Debug|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x64.Build.0 = Debug|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x86.ActiveCfg = Debug|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|ARM64.ActiveCfg = Release|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|ARM64.Build.0 = Release|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x64.ActiveCfg = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x64.Build.0 = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x86.ActiveCfg = Release|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|ARM64.Build.0 = Debug|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x64.ActiveCfg = Debug|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x64.Build.0 = Debug|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x86.ActiveCfg = Debug|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|ARM64.Build.0 = Release|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x64.Build.0 = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|ARM64.Build.0 = Debug|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x64.ActiveCfg = Debug|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x64.Build.0 = Debug|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x86.ActiveCfg = Debug|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|ARM64.Build.0 = Release|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x64.Build.0 = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x64.ActiveCfg = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|ARM64.ActiveCfg = Debug|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|ARM64.Build.0 = Debug|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|x64.ActiveCfg = Debug|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|x64.Build.0 = Debug|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|x86.ActiveCfg = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|ARM64.ActiveCfg = Release|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|ARM64.Build.0 = Release|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x64.ActiveCfg = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x64.Build.0 = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x64.ActiveCfg = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|ARM64.ActiveCfg = Debug|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|ARM64.Build.0 = Debug|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x64.ActiveCfg = Debug|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x64.Build.0 = Debug|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x86.ActiveCfg = Debug|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|ARM64.ActiveCfg = Release|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|ARM64.Build.0 = Release|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x64.ActiveCfg = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x64.Build.0 = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x86.ActiveCfg = Release|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x64.ActiveCfg = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|ARM64.ActiveCfg = Debug|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|ARM64.Build.0 = Debug|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x64.ActiveCfg = Debug|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x64.Build.0 = Debug|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x86.ActiveCfg = Debug|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|ARM64.ActiveCfg = Release|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|ARM64.Build.0 = Release|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x64.ActiveCfg = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x64.Build.0 = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x86.ActiveCfg = Release|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x64.ActiveCfg = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|ARM64.ActiveCfg = Debug|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|ARM64.Build.0 = Debug|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x64.ActiveCfg = Debug|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x64.Build.0 = Debug|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x86.ActiveCfg = Debug|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|ARM64.ActiveCfg = Release|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|ARM64.Build.0 = Release|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x64.ActiveCfg = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x64.Build.0 = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x86.ActiveCfg = Release|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x64.ActiveCfg = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|ARM64.ActiveCfg = Debug|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|ARM64.Build.0 = Debug|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x64.ActiveCfg = Debug|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x64.Build.0 = Debug|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x86.ActiveCfg = Debug|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|ARM64.ActiveCfg = Release|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|ARM64.Build.0 = Release|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x64.ActiveCfg = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x64.Build.0 = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x86.ActiveCfg = Release|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x64.ActiveCfg = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|ARM64.ActiveCfg = Debug|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|ARM64.Build.0 = Debug|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x64.ActiveCfg = Debug|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x64.Build.0 = Debug|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x86.ActiveCfg = Debug|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|ARM64.ActiveCfg = Release|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|ARM64.Build.0 = Release|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x64.ActiveCfg = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x64.Build.0 = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x86.ActiveCfg = Release|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|ARM64.ActiveCfg = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|ARM64.Build.0 = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x64.ActiveCfg = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x64.Build.0 = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x86.ActiveCfg = Debug|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|ARM64.ActiveCfg = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|ARM64.Build.0 = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x64.Build.0 = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|Any CPU.ActiveCfg = Debug|ARM64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|ARM64.ActiveCfg = Debug|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x64.ActiveCfg = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|ARM64.ActiveCfg = Debug|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x64.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x64.Build.0 = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x86.ActiveCfg = Debug|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|ARM64.ActiveCfg = Release|ARM64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x64.ActiveCfg = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x64.Build.0 = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x86.ActiveCfg = Release|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|Any CPU.ActiveCfg = Debug|ARM64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|ARM64.ActiveCfg = Debug|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x64.ActiveCfg = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|ARM64.ActiveCfg = Debug|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x64.ActiveCfg = Debug|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x64.Build.0 = Debug|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x86.ActiveCfg = Debug|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|ARM64.ActiveCfg = Release|ARM64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x64.ActiveCfg = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x64.Build.0 = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x86.ActiveCfg = Release|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x64.ActiveCfg = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|ARM64.ActiveCfg = Debug|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|ARM64.Build.0 = Debug|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x64.ActiveCfg = Debug|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x64.Build.0 = Debug|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x86.ActiveCfg = Debug|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|ARM64.ActiveCfg = Release|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|ARM64.Build.0 = Release|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x64.ActiveCfg = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x64.Build.0 = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x86.ActiveCfg = Release|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x64.ActiveCfg = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|ARM64.Build.0 = Debug|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x64.ActiveCfg = Debug|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x64.Build.0 = Debug|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x86.ActiveCfg = Debug|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|ARM64.ActiveCfg = Release|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|ARM64.Build.0 = Release|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x64.ActiveCfg = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x64.Build.0 = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x86.ActiveCfg = Release|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|ARM64.ActiveCfg = Debug|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|ARM64.Build.0 = Debug|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x64.ActiveCfg = Debug|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x64.Build.0 = Debug|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x86.ActiveCfg = Debug|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|ARM64.Build.0 = Release|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x64.Build.0 = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|ARM64.ActiveCfg = Debug|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|ARM64.Build.0 = Debug|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x64.ActiveCfg = Debug|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x64.Build.0 = Debug|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x86.ActiveCfg = Debug|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|ARM64.Build.0 = Release|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x64.Build.0 = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x64.ActiveCfg = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|ARM64.ActiveCfg = Debug|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|ARM64.Build.0 = Debug|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x64.ActiveCfg = Debug|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x64.Build.0 = Debug|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x86.ActiveCfg = Debug|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|ARM64.ActiveCfg = Release|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|ARM64.Build.0 = Release|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x64.ActiveCfg = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x64.Build.0 = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x86.ActiveCfg = Release|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x64.ActiveCfg = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|ARM64.Build.0 = Debug|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x64.ActiveCfg = Debug|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x64.Build.0 = Debug|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x86.ActiveCfg = Debug|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|ARM64.ActiveCfg = Release|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|ARM64.Build.0 = Release|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x64.ActiveCfg = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x64.Build.0 = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x86.ActiveCfg = Release|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|ARM64.ActiveCfg = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|ARM64.Build.0 = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x64.ActiveCfg = Debug|x64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x64.Build.0 = Debug|x64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x86.ActiveCfg = Debug|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Release|ARM64.Build.0 = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Release|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.Release|x64.Build.0 = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.Release|x86.ActiveCfg = Release|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x64.ActiveCfg = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|ARM64.ActiveCfg = Debug|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|ARM64.Build.0 = Debug|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x64.ActiveCfg = Debug|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x64.Build.0 = Debug|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x86.ActiveCfg = Debug|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|ARM64.ActiveCfg = Release|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Release|ARM64.Build.0 = Release|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x64.ActiveCfg = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x64.Build.0 = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x86.ActiveCfg = Release|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x64.ActiveCfg = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|ARM64.ActiveCfg = Debug|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|ARM64.Build.0 = Debug|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x64.ActiveCfg = Debug|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x64.Build.0 = Debug|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x86.ActiveCfg = Debug|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|ARM64.ActiveCfg = Release|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Release|ARM64.Build.0 = Release|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x64.ActiveCfg = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x64.Build.0 = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x86.ActiveCfg = Release|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.ActiveCfg = AuditMode|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.Build.0 = AuditMode|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.ActiveCfg = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.Build.0 = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.ActiveCfg = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.Build.0 = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.ActiveCfg = Debug|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.ActiveCfg = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.Build.0 = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.Build.0 = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|ARM64.ActiveCfg = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|ARM64.Build.0 = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x64.ActiveCfg = Debug|x64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x64.Build.0 = Debug|x64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x86.ActiveCfg = Debug|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Release|ARM64.Build.0 = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Release|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.Release|x64.Build.0 = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.Release|x86.ActiveCfg = Release|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x64.ActiveCfg = AuditMode|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x64.Build.0 = AuditMode|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|ARM64.ActiveCfg = Debug|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|ARM64.Build.0 = Debug|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x64.ActiveCfg = Debug|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x64.Build.0 = Debug|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x86.ActiveCfg = Debug|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|ARM64.ActiveCfg = Release|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|ARM64.Build.0 = Release|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x64.ActiveCfg = Release|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x64.Build.0 = Release|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x86.ActiveCfg = Release|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x64.ActiveCfg = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x64.Build.0 = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|ARM64.ActiveCfg = Debug|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|ARM64.Build.0 = Debug|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x64.ActiveCfg = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x64.Build.0 = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x86.ActiveCfg = Debug|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|ARM64.ActiveCfg = Release|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|ARM64.Build.0 = Release|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x64.ActiveCfg = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x64.Build.0 = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x86.ActiveCfg = Release|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
Apply audit mode to TerminalConnection/Core/Settings and WinCon… (#4016) ## Summary of the Pull Request - Enables auditing of some Terminal libraries (Connection, Core, Settings) - Also audit WinConPTY.LIB since Connection depends on it ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 19:44:27 +01:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
Apply audit mode to TerminalConnection/Core/Settings and WinCon… (#4016) ## Summary of the Pull Request - Enables auditing of some Terminal libraries (Connection, Core, Settings) - Also audit WinConPTY.LIB since Connection depends on it ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 19:44:27 +01:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|Any CPU.ActiveCfg = Debug|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|ARM64.ActiveCfg = Release|ARM64
Apply audit mode to TerminalConnection/Core/Settings and WinCon… (#4016) ## Summary of the Pull Request - Enables auditing of some Terminal libraries (Connection, Core, Settings) - Also audit WinConPTY.LIB since Connection depends on it ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 19:44:27 +01:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x64.ActiveCfg = AuditMode|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.Build.0 = Debug|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x64.ActiveCfg = Debug|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x64.Build.0 = Debug|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x86.ActiveCfg = Debug|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.ActiveCfg = Release|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.Build.0 = Release|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x64.ActiveCfg = Release|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x64.Build.0 = Release|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x86.ActiveCfg = Release|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x64.ActiveCfg = AuditMode|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x64.Build.0 = AuditMode|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|Any CPU.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|ARM64.ActiveCfg = Debug|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|ARM64.Build.0 = Debug|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x64.ActiveCfg = Debug|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x64.Build.0 = Debug|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x86.ActiveCfg = Debug|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|Any CPU.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|ARM64.ActiveCfg = Release|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|ARM64.Build.0 = Release|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x64.ActiveCfg = Release|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x64.Build.0 = Release|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x86.ActiveCfg = Release|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x64.ActiveCfg = AuditMode|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|Any CPU.ActiveCfg = Debug|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|ARM64.ActiveCfg = Debug|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|ARM64.Build.0 = Debug|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x64.ActiveCfg = Debug|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x64.Build.0 = Debug|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x86.ActiveCfg = Debug|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|Any CPU.ActiveCfg = Release|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|ARM64.ActiveCfg = Release|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|ARM64.Build.0 = Release|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x64.ActiveCfg = Release|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x64.Build.0 = Release|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x86.ActiveCfg = Release|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x64.ActiveCfg = AuditMode|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x64.Build.0 = AuditMode|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x86.Build.0 = AuditMode|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|Any CPU.ActiveCfg = Debug|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|ARM64.ActiveCfg = Debug|ARM64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x64.ActiveCfg = Debug|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x64.Build.0 = Debug|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x86.ActiveCfg = Debug|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x86.Build.0 = Debug|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|Any CPU.ActiveCfg = Release|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|ARM64.ActiveCfg = Release|ARM64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x64.ActiveCfg = Release|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x64.Build.0 = Release|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x86.ActiveCfg = Release|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x86.Build.0 = Release|Win32
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|Any CPU.ActiveCfg = Release|Any CPU
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|ARM64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|ARM64.Build.0 = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x64.Build.0 = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x86.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x86.Build.0 = Debug|Any CPU
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|Any CPU.Build.0 = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|ARM64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|x64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|x86.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|Any CPU.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|Any CPU.Build.0 = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|ARM64.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|x64.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|x86.ActiveCfg = Release|Any CPU
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|Any CPU.ActiveCfg = Release|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|Any CPU.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|Any CPU.ActiveCfg = Release|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x86.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x86.Build.0 = Release|Win32
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x64.ActiveCfg = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x64.Build.0 = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x86.Build.0 = AuditMode|Win32
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|Any CPU.ActiveCfg = Debug|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|ARM64.ActiveCfg = Debug|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|ARM64.Build.0 = Debug|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x64.ActiveCfg = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x64.Build.0 = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x86.ActiveCfg = Debug|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x86.Build.0 = Debug|Win32
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|Any CPU.ActiveCfg = Release|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|ARM64.ActiveCfg = Release|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|ARM64.Build.0 = Release|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x64.ActiveCfg = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x64.Build.0 = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x86.ActiveCfg = Release|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x86.Build.0 = Release|Win32
Introduce a WinRT utils library and "checked resources" (#3350) This commit introduces a C++/WinRT utility library and moves ScopedResourceLoader into it. I decided to get uppity and introduce something I like to call "checked resources." The idea is that every resource reference from a library is knowable at compile time, and we should be able to statically ensure that all resources exist. This is a system that lets us immediately failfast (on launch) when a library makes a static reference to a resource that doesn't exist at runtime. It exposes two new (preprocessor) APIs: * `RS_(wchar_t)`: loads a localizable string resource by name. * `USES_RESOURCE(wchar_t)`: marks a resource key as used, but is intended for loading images or passing static resource keys as parameters to functions that will look them up later. Resource checking relies on diligent use of `USES_RESOURCE()` and `RS_()` (which uses `USES_RESOURCE`), but can make sure we don't ship something that'll blow up at runtime. It works like this: **IN DEBUG MODE** - All resource names referenced through `USES_RESOURCE()` are emitted alongside their referencing filenames and line numbers into a static section of the binary. That section is named `.util$res$m`. - We emit two sentinel values into two different sections, `.util$res$a` and `.util$res$z`. - The linker sorts all sections alphabetically before crushing them together into the final binary. - When we first construct a library's scoped resource loader, we iterate over every resource reference between `$a` and `$z` and check residency. **IN RELEASE MODE** - All checked resource code is compiled out. Fixes #2146. Macros are the only way to do something this cool, incidentally. ## Validation Steps Performed Made references to a bunch of bad resources, tried to break it a lot. It looks like this when it fails: ### App.cpp ``` 36 static const std::array<std::wstring_view, 2> settingsLoadErrorsLabels { 37 USES_RESOURCE(L"NoProfilesText"), 38 USES_RESOURCE(L"AllProfilesHiddenText_HA_JUST_KIDDING") 39 }; ``` ``` WinRTUtils\LibraryResources.cpp(68)\TerminalApp.dll: FailFast(1) tid(1034) 8000FFFF Catastrophic failure Msg:[Resource AllProfilesHiddenText_HA_JUST_KIDDING not found in scope TerminalApp/Resources (App.cpp:38)] [EnsureAllResourcesArePresent] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|Any CPU.ActiveCfg = Release|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|ARM64.ActiveCfg = Release|ARM64
Enable Audit Mode for WinRTUtils (#3923) ## Summary of the Pull Request Turns on Audit for WinRTUtils, fixes audit failures. ## PR Checklist * [x] I work here * [x] Still builds * [x] Am core contributor. ## Validation Steps Performed Built it.
2019-12-12 14:28:32 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|x64.Build.0 = AuditMode|x64
Introduce a WinRT utils library and "checked resources" (#3350) This commit introduces a C++/WinRT utility library and moves ScopedResourceLoader into it. I decided to get uppity and introduce something I like to call "checked resources." The idea is that every resource reference from a library is knowable at compile time, and we should be able to statically ensure that all resources exist. This is a system that lets us immediately failfast (on launch) when a library makes a static reference to a resource that doesn't exist at runtime. It exposes two new (preprocessor) APIs: * `RS_(wchar_t)`: loads a localizable string resource by name. * `USES_RESOURCE(wchar_t)`: marks a resource key as used, but is intended for loading images or passing static resource keys as parameters to functions that will look them up later. Resource checking relies on diligent use of `USES_RESOURCE()` and `RS_()` (which uses `USES_RESOURCE`), but can make sure we don't ship something that'll blow up at runtime. It works like this: **IN DEBUG MODE** - All resource names referenced through `USES_RESOURCE()` are emitted alongside their referencing filenames and line numbers into a static section of the binary. That section is named `.util$res$m`. - We emit two sentinel values into two different sections, `.util$res$a` and `.util$res$z`. - The linker sorts all sections alphabetically before crushing them together into the final binary. - When we first construct a library's scoped resource loader, we iterate over every resource reference between `$a` and `$z` and check residency. **IN RELEASE MODE** - All checked resource code is compiled out. Fixes #2146. Macros are the only way to do something this cool, incidentally. ## Validation Steps Performed Made references to a bunch of bad resources, tried to break it a lot. It looks like this when it fails: ### App.cpp ``` 36 static const std::array<std::wstring_view, 2> settingsLoadErrorsLabels { 37 USES_RESOURCE(L"NoProfilesText"), 38 USES_RESOURCE(L"AllProfilesHiddenText_HA_JUST_KIDDING") 39 }; ``` ``` WinRTUtils\LibraryResources.cpp(68)\TerminalApp.dll: FailFast(1) tid(1034) 8000FFFF Catastrophic failure Msg:[Resource AllProfilesHiddenText_HA_JUST_KIDDING not found in scope TerminalApp/Resources (App.cpp:38)] [EnsureAllResourcesArePresent] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|Any CPU.ActiveCfg = Debug|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x86.Build.0 = Debug|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|Any CPU.ActiveCfg = Release|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x86.Build.0 = Release|Win32
Introduce a Universal package for Windows Terminal (#3236) This PR creates a Universal entrypoint for the Windows Terminal solution in search of our goals to run everywhere, on all Windows platforms. The Universal entrypoint is relatively straightforward and mostly just invokes the App without any of the other islands and win32 boilerplate required for the centennial route. The Universal project is also its own packaging project all in one and will emit a relevant APPX. A few things were required to make this work correctly: * Vcxitems reuse of resources (and link instructions on all of them for proper pkg layout) * Move all Terminal project CRT usages to the app ones (and ensure forwarders are only Nugetted to the Centennial package to not pollute the Universal one) * Fix/delay dependencies in `TerminalApp` that are not available in the core platform (or don't have an appropriate existing platform forwarder... do a loader snaps check) * vcpkg needs updating for the Azure connection parser * font fallbacks because Consolas isn't necessarily there * fallbacks because there are environments without a window handle Some of those happened in other small PRs in the past week or two. They were relevant to this. Note, this isn't *useful* as such yet. You can run the Terminal in this context and even get some of the shells to work. But they don't do a whole lot yet. Scoping which shells appear in the profiles list and only offering those that contextually make sense is future work. * Break everything out of App except the base initialization for XAML. AppLogic is the new home. * deduplicate logics by always using the app one (since it has to be there to support universal launch). * apparently that was too many cross-boundary calls and we can cache it because winrt objects are magic. * Put UWP project into solution. * tabs in titlebar needs disabling from uwp context as the non-client is way different. This adds a method to signal that to logic and apply the setting override. * Change to use App CRT in preparation for universal. * Try to make project build again by setting winconpty to static lib so it'll use the CRT inside TerminalConnection (or its other consumers) instead of linking its own. * Remove test for conpty dll, it's a lib now. Add additional commentary on how CRT linking works for future reference. I'm sure this will come up again. * This fixes the build error. * use the _apiset variant until proven otherwise to match the existing one. * Merge branch 'master' into dev/miniksa/uwp3 * recorrect spacing in cppwinrt.build.pre.props * Add multiple additional fonts to fallback to. Also, guard for invalid window handle on title update. * Remove ARMs from solution. * Share items resources between centennial and universal project. * cleanup resources and split manifest for dev/release builds. * Rev entire solution to latest Toolkit (6.0.0 stable release). * shorten the items file using include patterns * cleanup this filters file a bit. * Fix C26445 by using string_view as value, not ref. Don't build Universal in Audit because we're not auditing app yet. * some PR feedback. document losing the pointer. get rid of 16.3.9 workarounds. improve consistency of variable decl in applogic.h * Make dev phone product ID not match prod phone ID. Fix universal package identity to match proposed license information.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.Build.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.Deploy.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.Build.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.Deploy.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x64.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.ActiveCfg = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.Build.0 = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.Deploy.0 = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|Any CPU.ActiveCfg = Debug|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|ARM64.ActiveCfg = Debug|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.ActiveCfg = Debug|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.Build.0 = Debug|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.Deploy.0 = Debug|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.ActiveCfg = Debug|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.Build.0 = Debug|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.Deploy.0 = Debug|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|Any CPU.ActiveCfg = Release|Win32
Enable signing and ARM64 for Universal Terminal (#3716)
2019-11-26 23:25:54 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.ActiveCfg = Release|ARM64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.Build.0 = Release|ARM64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.Deploy.0 = Release|ARM64
Introduce a Universal package for Windows Terminal (#3236) This PR creates a Universal entrypoint for the Windows Terminal solution in search of our goals to run everywhere, on all Windows platforms. The Universal entrypoint is relatively straightforward and mostly just invokes the App without any of the other islands and win32 boilerplate required for the centennial route. The Universal project is also its own packaging project all in one and will emit a relevant APPX. A few things were required to make this work correctly: * Vcxitems reuse of resources (and link instructions on all of them for proper pkg layout) * Move all Terminal project CRT usages to the app ones (and ensure forwarders are only Nugetted to the Centennial package to not pollute the Universal one) * Fix/delay dependencies in `TerminalApp` that are not available in the core platform (or don't have an appropriate existing platform forwarder... do a loader snaps check) * vcpkg needs updating for the Azure connection parser * font fallbacks because Consolas isn't necessarily there * fallbacks because there are environments without a window handle Some of those happened in other small PRs in the past week or two. They were relevant to this. Note, this isn't *useful* as such yet. You can run the Terminal in this context and even get some of the shells to work. But they don't do a whole lot yet. Scoping which shells appear in the profiles list and only offering those that contextually make sense is future work. * Break everything out of App except the base initialization for XAML. AppLogic is the new home. * deduplicate logics by always using the app one (since it has to be there to support universal launch). * apparently that was too many cross-boundary calls and we can cache it because winrt objects are magic. * Put UWP project into solution. * tabs in titlebar needs disabling from uwp context as the non-client is way different. This adds a method to signal that to logic and apply the setting override. * Change to use App CRT in preparation for universal. * Try to make project build again by setting winconpty to static lib so it'll use the CRT inside TerminalConnection (or its other consumers) instead of linking its own. * Remove test for conpty dll, it's a lib now. Add additional commentary on how CRT linking works for future reference. I'm sure this will come up again. * This fixes the build error. * use the _apiset variant until proven otherwise to match the existing one. * Merge branch 'master' into dev/miniksa/uwp3 * recorrect spacing in cppwinrt.build.pre.props * Add multiple additional fonts to fallback to. Also, guard for invalid window handle on title update. * Remove ARMs from solution. * Share items resources between centennial and universal project. * cleanup resources and split manifest for dev/release builds. * Rev entire solution to latest Toolkit (6.0.0 stable release). * shorten the items file using include patterns * cleanup this filters file a bit. * Fix C26445 by using string_view as value, not ref. Don't build Universal in Audit because we're not auditing app yet. * some PR feedback. document losing the pointer. get rid of 16.3.9 workarounds. improve consistency of variable decl in applogic.h * Make dev phone product ID not match prod phone ID. Fix universal package identity to match proposed license information.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.Build.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.Deploy.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.ActiveCfg = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.Build.0 = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.Deploy.0 = Release|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
Apply audit mode to TerminalConnection/Core/Settings and WinCon… (#4016) ## Summary of the Pull Request - Enables auditing of some Terminal libraries (Connection, Core, Settings) - Also audit WinConPTY.LIB since Connection depends on it ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 19:44:27 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x64.ActiveCfg = AuditMode|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x64.Build.0 = AuditMode|x64
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x86.Build.0 = AuditMode|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|Any CPU.ActiveCfg = Debug|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|ARM64.ActiveCfg = Debug|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|ARM64.Build.0 = Debug|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x64.ActiveCfg = Debug|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x64.Build.0 = Debug|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x86.ActiveCfg = Debug|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x86.Build.0 = Debug|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|Any CPU.ActiveCfg = Release|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|ARM64.ActiveCfg = Release|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|ARM64.Build.0 = Release|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x64.ActiveCfg = Release|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x64.Build.0 = Release|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x86.ActiveCfg = Release|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x86.Build.0 = Release|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|x64.ActiveCfg = Release|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|x86.Build.0 = AuditMode|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|Any CPU.ActiveCfg = Debug|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|ARM64.ActiveCfg = Debug|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|ARM64.Build.0 = Debug|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x64.ActiveCfg = Debug|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x64.Build.0 = Debug|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x86.ActiveCfg = Debug|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x86.Build.0 = Debug|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|Any CPU.ActiveCfg = Release|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|ARM64.ActiveCfg = Release|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|ARM64.Build.0 = Release|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x64.ActiveCfg = Release|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x64.Build.0 = Release|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x86.ActiveCfg = Release|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x86.Build.0 = Release|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|Any CPU.ActiveCfg = AuditMode|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|x64.ActiveCfg = AuditMode|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|Any CPU.ActiveCfg = Debug|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|ARM64.ActiveCfg = Debug|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|ARM64.Build.0 = Debug|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|ARM64.Deploy.0 = Debug|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x64.ActiveCfg = Debug|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x64.Build.0 = Debug|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x64.Deploy.0 = Debug|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x86.ActiveCfg = Debug|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x86.Build.0 = Debug|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x86.Deploy.0 = Debug|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|Any CPU.ActiveCfg = Release|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|ARM64.ActiveCfg = Release|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|ARM64.Build.0 = Release|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|ARM64.Deploy.0 = Release|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x64.ActiveCfg = Release|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x64.Build.0 = Release|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x64.Deploy.0 = Release|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x86.ActiveCfg = Release|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x86.Build.0 = Release|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x86.Deploy.0 = Release|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|x64.ActiveCfg = Release|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|x86.Build.0 = AuditMode|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|Any CPU.ActiveCfg = Debug|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|ARM64.Build.0 = Debug|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x64.ActiveCfg = Debug|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x64.Build.0 = Debug|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x86.ActiveCfg = Debug|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x86.Build.0 = Debug|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|Any CPU.ActiveCfg = Release|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|ARM64.ActiveCfg = Release|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|ARM64.Build.0 = Release|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x64.ActiveCfg = Release|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x64.Build.0 = Release|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x86.ActiveCfg = Release|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x86.Build.0 = Release|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|Any CPU.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|Any CPU.Build.0 = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|ARM64.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|ARM64.Build.0 = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x64.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x64.Build.0 = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x86.ActiveCfg = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x86.Build.0 = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|Any CPU.ActiveCfg = Debug|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|ARM64.ActiveCfg = Debug|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x64.ActiveCfg = Debug|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x64.Build.0 = Debug|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x86.ActiveCfg = Debug|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x86.Build.0 = Debug|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|Any CPU.ActiveCfg = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|ARM64.ActiveCfg = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x64.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x64.Build.0 = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x86.ActiveCfg = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x86.Build.0 = Release|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|x64.ActiveCfg = Release|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|x86.Build.0 = AuditMode|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|Any CPU.ActiveCfg = Debug|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|ARM64.ActiveCfg = Debug|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|ARM64.Build.0 = Debug|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x64.ActiveCfg = Debug|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x64.Build.0 = Debug|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x86.ActiveCfg = Debug|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x86.Build.0 = Debug|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|Any CPU.ActiveCfg = Release|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|ARM64.ActiveCfg = Release|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|ARM64.Build.0 = Release|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x64.ActiveCfg = Release|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x64.Build.0 = Release|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x86.ActiveCfg = Release|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x86.Build.0 = Release|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|x64.ActiveCfg = Release|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|x86.Build.0 = AuditMode|Win32
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|Any CPU.ActiveCfg = Debug|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|ARM64.ActiveCfg = Debug|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|ARM64.Build.0 = Debug|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x64.ActiveCfg = Debug|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x64.Build.0 = Debug|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x86.ActiveCfg = Debug|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x86.Build.0 = Debug|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|Any CPU.ActiveCfg = Release|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|ARM64.ActiveCfg = Release|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|ARM64.Build.0 = Release|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x64.ActiveCfg = Release|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x64.Build.0 = Release|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x86.ActiveCfg = Release|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x86.Build.0 = Release|Win32
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|Any CPU.ActiveCfg = Debug|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|ARM64.ActiveCfg = Debug|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|ARM64.Build.0 = Debug|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x64.ActiveCfg = Debug|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x64.Build.0 = Debug|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x86.ActiveCfg = Debug|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x86.Build.0 = Debug|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|Any CPU.ActiveCfg = Release|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|ARM64.ActiveCfg = Release|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|ARM64.Build.0 = Release|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x64.ActiveCfg = Release|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x64.Build.0 = Release|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x86.ActiveCfg = Release|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x86.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
GlobalSection(NestedProjects) = preSolution
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12} = {59840756-302F-44DF-AA47-441A9D673202}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{4C8E6BB0-4713-4ADB-BD04-81628ECEAF20} = {81C352DB-1818-45B7-A284-18E259F1CC87}
{D57841D1-8294-4F2B-BB8B-D2A35738DECD} = {81C352DB-1818-45B7-A284-18E259F1CC87}
{2FD12FBB-1DDB-46D8-B818-1023C624CACA} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{3AE13314-1939-4DFA-9C14-38CA0834050C} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{DCF55140-EF6A-4736-A403-957E4F7430BB} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{1CF55140-EF6A-4736-A403-957E4F7430BB} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{1C959542-BAC2-4E55-9A6D-13251914CBB9} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{06EC74CB-9A12-429C-B551-8562EC954746} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{06EC74CB-9A12-429C-B551-8562EC954747} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{531C23E7-4B76-4C08-8AAD-04164CB628C9} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{531C23E7-4B76-4C08-8BBD-04164CB628C9} = {1E4A062E-293B-4817-B20D-BF16B979E350}
{8CDB8850-7484-4EC7-B45B-181F85B2EE54} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{12144E07-FE63-4D33-9231-748B8D8C3792} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{6AF01638-84CF-4B65-9870-484DFFCAC772} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{F210A4AE-E02A-4BFC-80BB-F50A672FE763} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{18D09A24-8240-42D6-8CB6-236EEE820262} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{C17E1BF3-9D34-4779-9458-A8EF98CC5662} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{099193A0-1E43-4BBC-BA7F-7B351E1342DF} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{FC802440-AD6A-4919-8F2C-7701F2B38D79} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{919544AC-D39B-463F-8414-3C3C67CF727C} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{ED82003F-FC5D-4E94-8B36-F480018ED064} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{06EC74CB-9A12-429C-B551-8532EC964726} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{ED82003F-FC5D-4E94-8B47-F480018ED064} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{06EC74CB-9A12-429C-B551-8562EC964846} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{990F2657-8580-4828-943F-5DD657D11842} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{814DBDDE-894E-4327-A6E1-740504850098} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{814CBEEE-894E-4327-A6E1-740504850098} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{18D09A24-8240-42D6-8CB6-236EEE820263} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{990F2657-8580-4828-943F-5DD657D11843} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {1E4A062E-293B-4817-B20D-BF16B979E350}
{48D21369-3D7B-4431-9967-24E81292CF62} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {59840756-302F-44DF-AA47-441A9D673202}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{16376381-CE22-42BE-B667-C6B35007008D} = {81C352DB-1818-45B7-A284-18E259F1CC87}
{F1995847-4AE5-479A-BBAF-382E51A63532} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{05500DEF-2294-41E3-AF9A-24E580B82836} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{1E4A062E-293B-4817-B20D-BF16B979E350} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890} = {59840756-302F-44DF-AA47-441A9D673202}
{376FE273-6B84-4EB5-8B30-8DE9D21B022C} = {59840756-302F-44DF-AA47-441A9D673202}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {59840756-302F-44DF-AA47-441A9D673202}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63} = {05500DEF-2294-41E3-AF9A-24E580B82836}
Introduce a WinRT utils library and "checked resources" (#3350) This commit introduces a C++/WinRT utility library and moves ScopedResourceLoader into it. I decided to get uppity and introduce something I like to call "checked resources." The idea is that every resource reference from a library is knowable at compile time, and we should be able to statically ensure that all resources exist. This is a system that lets us immediately failfast (on launch) when a library makes a static reference to a resource that doesn't exist at runtime. It exposes two new (preprocessor) APIs: * `RS_(wchar_t)`: loads a localizable string resource by name. * `USES_RESOURCE(wchar_t)`: marks a resource key as used, but is intended for loading images or passing static resource keys as parameters to functions that will look them up later. Resource checking relies on diligent use of `USES_RESOURCE()` and `RS_()` (which uses `USES_RESOURCE`), but can make sure we don't ship something that'll blow up at runtime. It works like this: **IN DEBUG MODE** - All resource names referenced through `USES_RESOURCE()` are emitted alongside their referencing filenames and line numbers into a static section of the binary. That section is named `.util$res$m`. - We emit two sentinel values into two different sections, `.util$res$a` and `.util$res$z`. - The linker sorts all sections alphabetically before crushing them together into the final binary. - When we first construct a library's scoped resource loader, we iterate over every resource reference between `$a` and `$z` and check residency. **IN RELEASE MODE** - All checked resource code is compiled out. Fixes #2146. Macros are the only way to do something this cool, incidentally. ## Validation Steps Performed Made references to a bunch of bad resources, tried to break it a lot. It looks like this when it fails: ### App.cpp ``` 36 static const std::array<std::wstring_view, 2> settingsLoadErrorsLabels { 37 USES_RESOURCE(L"NoProfilesText"), 38 USES_RESOURCE(L"AllProfilesHiddenText_HA_JUST_KIDDING") 39 }; ``` ``` WinRTUtils\LibraryResources.cpp(68)\TerminalApp.dll: FailFast(1) tid(1034) 8000FFFF Catastrophic failure Msg:[Resource AllProfilesHiddenText_HA_JUST_KIDDING not found in scope TerminalApp/Resources (App.cpp:38)] [EnsureAllResourcesArePresent] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE} = {59840756-302F-44DF-AA47-441A9D673202}
Introduce a Universal package for Windows Terminal (#3236) This PR creates a Universal entrypoint for the Windows Terminal solution in search of our goals to run everywhere, on all Windows platforms. The Universal entrypoint is relatively straightforward and mostly just invokes the App without any of the other islands and win32 boilerplate required for the centennial route. The Universal project is also its own packaging project all in one and will emit a relevant APPX. A few things were required to make this work correctly: * Vcxitems reuse of resources (and link instructions on all of them for proper pkg layout) * Move all Terminal project CRT usages to the app ones (and ensure forwarders are only Nugetted to the Centennial package to not pollute the Universal one) * Fix/delay dependencies in `TerminalApp` that are not available in the core platform (or don't have an appropriate existing platform forwarder... do a loader snaps check) * vcpkg needs updating for the Azure connection parser * font fallbacks because Consolas isn't necessarily there * fallbacks because there are environments without a window handle Some of those happened in other small PRs in the past week or two. They were relevant to this. Note, this isn't *useful* as such yet. You can run the Terminal in this context and even get some of the shells to work. But they don't do a whole lot yet. Scoping which shells appear in the profiles list and only offering those that contextually make sense is future work. * Break everything out of App except the base initialization for XAML. AppLogic is the new home. * deduplicate logics by always using the app one (since it has to be there to support universal launch). * apparently that was too many cross-boundary calls and we can cache it because winrt objects are magic. * Put UWP project into solution. * tabs in titlebar needs disabling from uwp context as the non-client is way different. This adds a method to signal that to logic and apply the setting override. * Change to use App CRT in preparation for universal. * Try to make project build again by setting winconpty to static lib so it'll use the CRT inside TerminalConnection (or its other consumers) instead of linking its own. * Remove test for conpty dll, it's a lib now. Add additional commentary on how CRT linking works for future reference. I'm sure this will come up again. * This fixes the build error. * use the _apiset variant until proven otherwise to match the existing one. * Merge branch 'master' into dev/miniksa/uwp3 * recorrect spacing in cppwinrt.build.pre.props * Add multiple additional fonts to fallback to. Also, guard for invalid window handle on title update. * Remove ARMs from solution. * Share items resources between centennial and universal project. * cleanup resources and split manifest for dev/release builds. * Rev entire solution to latest Toolkit (6.0.0 stable release). * shorten the items file using include patterns * cleanup this filters file a bit. * Fix C26445 by using string_view as value, not ref. Don't build Universal in Audit because we're not auditing app yet. * some PR feedback. document losing the pointer. get rid of 16.3.9 workarounds. improve consistency of variable decl in applogic.h * Make dev phone product ID not match prod phone ID. Fix universal package identity to match proposed license information.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1} = {59840756-302F-44DF-AA47-441A9D673202}
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{A22EC5F6-7851-4B88-AC52-47249D437A52} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
{BDB237B6-1D1D-400F-84CC-40A58FA59C8E} = {59840756-302F-44DF-AA47-441A9D673202}
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1} = {A10C4720-DCA4-4640-9749-67F4314F527C}
Move tests to invoke `te.exe` directly instead of using VSTest runner (#4490) Moves the tests from using the `vstest.console.exe` route to just using `te.exe`. PROs: - `te.exe` is significantly faster for running tests because the TAEF/VSTest adapter isn't great. - Running through `te.exe` is closer to what our developers are doing on their dev boxes - `te.exe` is how they run in the Windows gates. - `te.exe` doesn't seem to have the sporadic `0x6` error code thrown during the tests where somehow the console handles get lost - `te.exe` doesn't seem to repro the other intermittent issues that we have been having that are inscrutable. - Fewer processes in the tree (te is running anyway under `vstest.console.exe`, just indirected a lot - The log outputs scroll live with all our logging messages instead of suppressing everything until there's a failure - The log output is actually in the order things are happening versus vstest. CONs: - No more code coverage. - No more test records in the ADO build/test panel. - Tests really won't work inside Visual Studio at all. - The log files are really big now - Testing is not a test task anymore, just another script. Refuting each CON: - We didn't read the code coverage numbers - We didn't look at the ADO test panel results or build-over-build velocities - Tests didn't really work inside Visual Studio anyway unless you did the right incantations under the full moon. - We could tone down the logging if we wanted at either the te.exe execution time (with a switch) or by declaring properties in the tests/classes/modules that are very verbose to not log unless it fails. - I don't think anyone cares how they get run as long as they do.
2020-02-10 20:14:06 +01:00
{53DD5520-E64C-4C06-B472-7CE62CA539C9} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
{6B5A44ED-918D-4747-BFB1-2472A1FCA173} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
{D3EF7B96-CD5E-47C9-B9A9-136259563033} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4} = {05500DEF-2294-41E3-AF9A-24E580B82836}
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D} = {59840756-302F-44DF-AA47-441A9D673202}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
SolutionGuid = {3140B1B7-C8EE-43D1-A772-D82A7061A271}
EndGlobalSection
EndGlobal