maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/LocalTests_TerminalApp/TerminalApp.LocalTests.vcxproj

103 lines
5.4 KiB
XML
Raw Normal View History

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
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
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
<!-- A note about this project: We're building the test code dll from this
project, but it _MUST_ be run in conjunction with the TestHostApp project.
TestHostApp actually will build a TestHost executable and packaging bits
that we can use to run our tests. We need TestHostApp so that our
dependencies, like MUX, can be aggregated correctly, and resources properly
combined into a resources.pri file.
TestHostApp will manually copy the output of this project into it's own
OutDir, so we can run the tests from there. -->
Unify and clean up the common build properties (#3429) This commit cleans up and deduplicates all of the common build preamble/postamble across exe, dll, lib and c++/winrt projects. The following specific changes have been made: * All projects now define their ConfigurationType * All projects now set all their properties *before* including a common build file (or any other build files) * cppwinrt.pre and cppwinrt.post now delegate most of their configuration to common.pre and common.post * (becuase of the above,) all build options are conserved between console and c++/winrt components, including specific warnings and preprocessor definitions. * More properties that are configurable per-project are now conditioned so the common props don't override them. * The exe, dll, exe.or.dll, and lib postincludes have been merged into pre or post and switched based on condition as required * Shared items (-shared, -common) are now explicitly vcxitems instead of vcxproj files. * The link line is now manipulated after Microsoft.Cpp sets it, so the libraries we specify "win". All console things link first against onecore_apiset.lib. * Fix all compilation errors caused by build unification * Move CascadiaPackage's resources into a separate item file Fixes #922.
2019-11-05 23:29:11 +01:00
<PropertyGroup>
<ProjectGuid>{CA5CAD1A-b11c-4ddb-a4fe-c3afae9b5506}</ProjectGuid>
<Keyword>Win32Proj</Keyword>
<RootNamespace>TerminalAppLocalTests</RootNamespace>
<ProjectName>LocalTests_TerminalApp</ProjectName>
<TargetName>TerminalApp.LocalTests</TargetName>
<ConfigurationType>DynamicLibrary</ConfigurationType>
Remove all our path antics; force native projects to bin/, obj/ (#8062) This commit fixes our longstanding build artifact output issues and finally unifies all C++ project output into bin/ and obj/. In light of that, I've removed NoOutputRedirection. I've also updated WTU and U8U16Test to use our common build props and fixed any warnings/compilation errors that popped out. I validated this change by running repeated incremental builds after changing individual .cpp files in many of our C++/WinRT projects.
2020-10-27 23:00:41 +01:00
<OpenConsoleCppWinRTProject>true</OpenConsoleCppWinRTProject>
Unify and clean up the common build properties (#3429) This commit cleans up and deduplicates all of the common build preamble/postamble across exe, dll, lib and c++/winrt projects. The following specific changes have been made: * All projects now define their ConfigurationType * All projects now set all their properties *before* including a common build file (or any other build files) * cppwinrt.pre and cppwinrt.post now delegate most of their configuration to common.pre and common.post * (becuase of the above,) all build options are conserved between console and c++/winrt components, including specific warnings and preprocessor definitions. * More properties that are configurable per-project are now conditioned so the common props don't override them. * The exe, dll, exe.or.dll, and lib postincludes have been merged into pre or post and switched based on condition as required * Shared items (-shared, -common) are now explicitly vcxitems instead of vcxproj files. * The link line is now manipulated after Microsoft.Cpp sets it, so the libraries we specify "win". All console things link first against onecore_apiset.lib. * Fix all compilation errors caused by build unification * Move CascadiaPackage's resources into a separate item file Fixes #922.
2019-11-05 23:29:11 +01:00
</PropertyGroup>
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
<Import Project="$(SolutionDir)\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
Fix the TabTests! (#3833) ## Summary of the Pull Request Fix the `TabTests`, and enable testing of types with XAML content. The `TabTests` were written many, many moons ago. they were intended to be our tests of XAML-like content within the Terminal app, so we could have unittests of Tabs, Panes, etc. Between their initial authoring and the day they were checked in, we had a bunch of build changes come in and break them irreperably. We've gotten them fixed now with _one weird trick_ <sup>doctors hate me</sup>. As long as there isn't an `App.xbf` in the test's output directory, then the tests will deploy just fine. We also needed a bit of magic, cribbed straight from TAEF, to enable running test code synchronously on the UI thread. Hence, `CppwinrtTailored.h`. ## References ## PR Checklist * [x] Closes #2472 * [x] I work here * [x] Tests added/passed - you better believe it * [n/a] Requires documentation to be updated ## Validation Steps Performed ![image](https://user-images.githubusercontent.com/18356694/70185192-ef1d0b00-16ae-11ea-8799-b77061e3cdb0.png)
2019-12-06 21:45:08 +01:00
<Import Project="$(OpenConsoleDir)\src\cppwinrt.build.pre.props" />
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
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
<ItemDefinitionGroup>
<ClCompile>
<!-- For CLI11: It uses dynamic_cast to cast types around, which depends
on being compiled with RTTI (/GR). -->
<RuntimeTypeInfo>true</RuntimeTypeInfo>
</ClCompile>
</ItemDefinitionGroup>
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
<!-- ========================= Headers ======================== -->
<ItemGroup>
Fix the TabTests! (#3833) ## Summary of the Pull Request Fix the `TabTests`, and enable testing of types with XAML content. The `TabTests` were written many, many moons ago. they were intended to be our tests of XAML-like content within the Terminal app, so we could have unittests of Tabs, Panes, etc. Between their initial authoring and the day they were checked in, we had a bunch of build changes come in and break them irreperably. We've gotten them fixed now with _one weird trick_ <sup>doctors hate me</sup>. As long as there isn't an `App.xbf` in the test's output directory, then the tests will deploy just fine. We also needed a bit of magic, cribbed straight from TAEF, to enable running test code synchronously on the UI thread. Hence, `CppwinrtTailored.h`. ## References ## PR Checklist * [x] Closes #2472 * [x] I work here * [x] Tests added/passed - you better believe it * [n/a] Requires documentation to be updated ## Validation Steps Performed ![image](https://user-images.githubusercontent.com/18356694/70185192-ef1d0b00-16ae-11ea-8799-b77061e3cdb0.png)
2019-12-06 21:45:08 +01:00
<ClInclude Include="pch.h" />
<ClInclude Include="CppWinrtTailored.h" />
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
</ItemGroup>
<!-- ========================= Cpp Files ======================== -->
<ItemGroup>
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
<ClCompile Include="CommandlineTest.cpp" />
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
<ClCompile Include="SettingsTests.cpp" />
<ClCompile Include="TabTests.cpp" />
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<ClCompile Include="FilteredCommandTests.cpp" />
Fix the TabTests! (#3833) ## Summary of the Pull Request Fix the `TabTests`, and enable testing of types with XAML content. The `TabTests` were written many, many moons ago. they were intended to be our tests of XAML-like content within the Terminal app, so we could have unittests of Tabs, Panes, etc. Between their initial authoring and the day they were checked in, we had a bunch of build changes come in and break them irreperably. We've gotten them fixed now with _one weird trick_ <sup>doctors hate me</sup>. As long as there isn't an `App.xbf` in the test's output directory, then the tests will deploy just fine. We also needed a bit of magic, cribbed straight from TAEF, to enable running test code synchronously on the UI thread. Hence, `CppwinrtTailored.h`. ## References ## PR Checklist * [x] Closes #2472 * [x] I work here * [x] Tests added/passed - you better believe it * [n/a] Requires documentation to be updated ## Validation Steps Performed ![image](https://user-images.githubusercontent.com/18356694/70185192-ef1d0b00-16ae-11ea-8799-b77061e3cdb0.png)
2019-12-06 21:45:08 +01:00
<ClCompile Include="pch.cpp">
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
<PrecompiledHeader>Create</PrecompiledHeader>
</ClCompile>
</ItemGroup>
<!-- ========================= Project References ======================== -->
<ItemGroup>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ProjectReference Include="$(OpenConsoleDir)\src\cascadia\TerminalApp\TerminalAppLib.vcxproj" />
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
<ProjectReference Include="$(OpenConsoleDir)\src\types\lib\types.vcxproj" />
<!-- If you don't reference these projects here, the
_ConsoleGenerateAdditionalWinmdManifests step won't gather the winmd's -->
Add a keybinding option to Terminal to open the Settings UI (#8048) This commit iontroduces another `target` to the `openSettings` binding: `settingsUI`. It opens the settings UI introduced in the previous commit. Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com>
2020-12-11 22:34:57 +01:00
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalSettingsEditor\Microsoft.Terminal.Settings.Editor.vcxproj" />
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalControl\dll\TerminalControl.vcxproj" />
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
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalConnection\TerminalConnection.vcxproj" />
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
<ProjectReference Include="$(OpenConsoleDir)\src\cascadia\TerminalApp\dll\TerminalApp.vcxproj" />
<ProjectReference Include="$(OpenConsoleDir)\src\cascadia\TerminalSettingsModel\dll\Microsoft.Terminal.Settings.Model.vcxproj" />
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
</ItemGroup>
<!-- ========================= Globals ======================== -->
<!-- ====================== Compiler & Linker Flags ===================== -->
<ItemDefinitionGroup>
<ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<AdditionalIncludeDirectories>..;$(OpenConsoleDir)\dep;$(OpenConsoleDir)\dep\jsoncpp\json;$(OpenConsoleDir)src\inc;$(OpenConsoleDir)src\inc\test;$(WinRT_IncludePath)\..\cppwinrt\winrt;"$(OpenConsoleDir)\src\cascadia\TerminalApp\Generated Files";%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
Fix the TabTests! (#3833) ## Summary of the Pull Request Fix the `TabTests`, and enable testing of types with XAML content. The `TabTests` were written many, many moons ago. they were intended to be our tests of XAML-like content within the Terminal app, so we could have unittests of Tabs, Panes, etc. Between their initial authoring and the day they were checked in, we had a bunch of build changes come in and break them irreperably. We've gotten them fixed now with _one weird trick_ <sup>doctors hate me</sup>. As long as there isn't an `App.xbf` in the test's output directory, then the tests will deploy just fine. We also needed a bit of magic, cribbed straight from TAEF, to enable running test code synchronously on the UI thread. Hence, `CppwinrtTailored.h`. ## References ## PR Checklist * [x] Closes #2472 * [x] I work here * [x] Tests added/passed - you better believe it * [n/a] Requires documentation to be updated ## Validation Steps Performed ![image](https://user-images.githubusercontent.com/18356694/70185192-ef1d0b00-16ae-11ea-8799-b77061e3cdb0.png)
2019-12-06 21:45:08 +01:00
<PrecompiledHeaderFile>pch.h</PrecompiledHeaderFile>
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
<!-- Manually disable unreachable code warning, because jconcpp has a ton of that. -->
<DisableSpecificWarnings>4702;%(DisableSpecificWarnings)</DisableSpecificWarnings>
</ClCompile>
<Link>
Fix the TabTests! (#3833) ## Summary of the Pull Request Fix the `TabTests`, and enable testing of types with XAML content. The `TabTests` were written many, many moons ago. they were intended to be our tests of XAML-like content within the Terminal app, so we could have unittests of Tabs, Panes, etc. Between their initial authoring and the day they were checked in, we had a bunch of build changes come in and break them irreperably. We've gotten them fixed now with _one weird trick_ <sup>doctors hate me</sup>. As long as there isn't an `App.xbf` in the test's output directory, then the tests will deploy just fine. We also needed a bit of magic, cribbed straight from TAEF, to enable running test code synchronously on the UI thread. Hence, `CppwinrtTailored.h`. ## References ## PR Checklist * [x] Closes #2472 * [x] I work here * [x] Tests added/passed - you better believe it * [n/a] Requires documentation to be updated ## Validation Steps Performed ![image](https://user-images.githubusercontent.com/18356694/70185192-ef1d0b00-16ae-11ea-8799-b77061e3cdb0.png)
2019-12-06 21:45:08 +01:00
<AdditionalDependencies>onecoreuap.lib;%(AdditionalDependencies)</AdditionalDependencies>
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
</Link>
</ItemDefinitionGroup>
<PropertyGroup>
<GenerateManifest>true</GenerateManifest>
<EmbedManifest>true</EmbedManifest>
</PropertyGroup>
<!-- Careful reordering these. Some default props (contained in these files) are order sensitive. -->
<Import Project="$(OpenConsoleDir)src\common.build.post.props" />
<Import Project="$(OpenConsoleDir)src\common.build.tests.props" />
<PropertyGroup>
<!-- From Microsoft.UI.Xaml.targets -->
<Native-Platform Condition="'$(Platform)' == 'Win32'">x86</Native-Platform>
<Native-Platform Condition="'$(Platform)' != 'Win32'">$(Platform)</Native-Platform>
Update to MUX 2.7 (#11240) * this is the same thing as #10996, but with the fix that caused us to #11031 * This includes https://github.com/microsoft/microsoft-ui-xaml/pull/3769, so we had to make some adjustments to how we handle tab colors. It works the same as before. * Should enable #11231 to be started * [x] Closes #10508 * [x] Closes #7133 * [x] Closes #8948 * [ ] I need to finish letting my 19H1 VM boot to make sure unpackaged still works
2021-09-21 00:08:55 +02:00
<_MUXBinRoot>&quot;$(OpenConsoleDir)packages\Microsoft.UI.Xaml.2.7.0-prerelease.210913003\runtimes\win10-$(Native-Platform)\native\&quot;</_MUXBinRoot>
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
</PropertyGroup>
<!-- We actually can just straight up reference MUX here, it's fine -->
Update to MUX 2.7 (#11240) * this is the same thing as #10996, but with the fix that caused us to #11031 * This includes https://github.com/microsoft/microsoft-ui-xaml/pull/3769, so we had to make some adjustments to how we handle tab colors. It works the same as before. * Should enable #11231 to be started * [x] Closes #10508 * [x] Closes #7133 * [x] Closes #8948 * [ ] I need to finish letting my 19H1 VM boot to make sure unpackaged still works
2021-09-21 00:08:55 +02:00
<Import Project="..\..\..\packages\Microsoft.UI.Xaml.2.7.0-prerelease.210913003\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.7.0-prerelease.210913003\build\native\Microsoft.UI.Xaml.targets')" />
Update Xaml Toolkit App Host to 6.1.3 (#10640) This is required for some inbox compliance tasks regarding symbol availability.
2021-07-13 00:58:02 +02:00
<Import Project="..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.3\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets" Condition="Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.3\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets')" />
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>
Reference in a new issue Copy permalink