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

136 lines
6.3 KiB
XML
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
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="Globals">
<ProjectGuid>{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}</ProjectGuid>
<ProjectName>TerminalConnection</ProjectName>
<RootNamespace>Microsoft.Terminal.TerminalConnection</RootNamespace>
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
<ConfigurationType>DynamicLibrary</ConfigurationType>
<SubSystem>Console</SubSystem>
<OpenConsoleUniversalApp>true</OpenConsoleUniversalApp>
Implement PGO in pipelines for AMD64 architecture; supply training test scenarios (#10071) Implement PGO in pipelines for AMD64 architecture; supply training test scenarios ## References - #3075 - Relevant to speed interests there and other linked issues. ## PR Checklist * [x] Closes #6963 * [x] I work here. * [x] New UIA Tests added and passed. Manual build runs also tested. ## Detailed Description of the Pull Request / Additional comments - Creates a new pipeline run for creating instrumented binaries for Profile Guided Optimization (PGO). - Creates a new suite of UIA tests on the full Windows Terminal app to run PGO training scenarios on instrumented binaries (and incidentally can be used to write other UIA tests later for the full Terminal app.) - Creates a new NuGet artifact to store trained PGO databases (PGD files) at `Microsoft.Internal.Windows.Terminal.PGODatabase` - Creates a new NuGet artifact to supply large-scale test content for automated tests at `Microsoft.Internal.Windows.Terminal.TestContent` - Adjusts the release pipeline to run binaries in PGO optimized mode where content from PGO databases is leveraged at link time to optimize the final release build The following binaries are trained: - OpenConsole.exe - WindowsTerminal.exe - TerminalApp.dll - TerminalConnection.dll - Microsoft.Terminal.Control.dll - Microsoft.Terminal.Remoting.dll - Microsoft.Terminal.Settings.Editor.dll - Microsoft.Terminal.Settings.Model.dll In the future, adding `<PgoTarget>true</PgoTarget>` to a new `vcxproj` file will automatically enroll the DLL/EXE for PGO instrumentation and optimization going forward. Two training test scenarios are implemented: - Smoke test the Terminal by just opening it and typing a bit of text then exiting. (Should help focus on the standard launch path.) - Optimize bulk text output by launching terminal, outputting `big.txt`, then exiting. Additional scenarios can be contributed to the `WindowsTerminal_UIATests` project with the `[TestProperty("IsPGO", "true")]` annotation to add them to the suite of scenarios for PGO. **NOTE:** There are currently no weights applied to the various test scenarios. We will revisit that in the future when/if necessary. ## Validation Steps Performed - [x] - Training run completed at https://dev.azure.com/ms/terminal/_build?definitionId=492&_a=summary - [x] - Optimization run completed locally (by forcing `PGOBuildMode` to `Optimize` on my local machine, manually retrieving the databases with NuGet, and building). - [x] - Validated locally that x86 and ARM64 do not get trained and automatically skip optimization as databases are not present for them. - [x] - Smoke tested optimized binary versus latest releases. `big.txt` output through CMD is ~11-12seconds prior to PGO and just over 8 seconds with PGO.
2021-05-13 23:12:30 +02:00
<PgoTarget>true</PgoTarget>
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
</PropertyGroup>
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
<Import Project="..\..\..\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.pre.props" />
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
<ItemGroup>
replace vcpkg-cpprestsdk with a +ARM64 -ssl/boost +UWP version (#3489) This new cpprestsdk package, 2.10.14, switches us to the app CRT. cpprestsdk turns fof a bunch of boost and openssl dependencies when it's built for the Windows Store subplatform, so we got a bunch of stuff for free. Incidentally, I fixed #2338 the real/correct way -- the build rules in the package now make sure they're not using the system vcpkg root.
2019-11-08 23:17:11 +01:00
<ClInclude Include="AzureClientID.h" />
Switch Connections to use `ValueSet`s to initialize them (#10184) #### ⚠️ targets #10051 ## Summary of the Pull Request This PR does one big, primary thing. It removes all the constructors from any TerminalConnections, and changes them to use an `Initialize` method that accepts a `ValueSet` of properties. Why? For the upcoming window/content process work, we'll need the content process to be able to initialize the connection _in the content process_. However, the window process will be the one that knows what type of connection to make. Enter `ConnectionInformation`. This class will let us specify the class name of the type we want to create, and a set of settings to use when initializing that connection. **IMPORTANT**: As a part of this, the constructor for a connection must have 0 arguments. `RoActivateInstance` lets you just conjure a WinRT type just by class name, but that class must have a 0 arg ctor. Hence the need for `Initialize`, to actually pass the settings. We're using a `ValueSet` here because it's basically a json blob, with more steps. In the future, when extension authors want to have custom connections, we can always deserialize the json into a `ValueSet`, pass it to their connection's `Initialize`, and let then get what they need out of it. ## References * Tear-out: #1256 * Megathread: #5000 * Project: https://github.com/microsoft/terminal/projects/5 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760298 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments `ConnectionInformation` was included as a part of this PR, to demonstrate how this will eventually be used. `ConnectionInformation` is not _currently_ used. ## Validation Steps Performed It still builds and runs.
2021-07-20 17:02:17 +02:00
<ClInclude Include="ConnectionInformation.h">
<DependentUpon>ConnectionInformation.idl</DependentUpon>
</ClInclude>
Create Telnet connection type and default loopback profile for… (#3858) For our Universal terminal for development purposes, we will use telnet to escape the universal application container and empower developers to debug/diagnose issues with their own machine on loopback to the already-elevated telnet context.
2019-12-09 20:07:08 +01:00
<ClInclude Include="AzureConnection.h">
<DependentUpon>AzureConnection.idl</DependentUpon>
</ClInclude>
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
<ClInclude Include="CTerminalHandoff.h" />
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
<ClInclude Include="pch.h" />
Replace ConhostConnection with ConptyConnection (#3461) This commit deletes ConhostConnection and replaces it with ConptyConnection. The ConptyConnection uses CreatePseudoConsole and depends on winconpty to override the one from kernel32. * winconpty must be packageable, so I've added GetPackagingOutputs. * To validate this, I added conpty.dll to the MSIX regression script. * I moved the code from conpty-universal that deals with environment strings into the types library. This puts us in a way better place to implement #2563, as we can now separately detect a failure to launch a pseudoconsole, a failure to CreateProcess, and an unexpected termination of the launched process. Fixes #1131.
2019-11-07 00:09:01 +01:00
<ClInclude Include="ConptyConnection.h">
<DependentUpon>ConptyConnection.idl</DependentUpon>
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
</ClInclude>
<ClInclude Include="EchoConnection.h">
<DependentUpon>EchoConnection.idl</DependentUpon>
</ClInclude>
</ItemGroup>
<ItemGroup>
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
<ClCompile Include="CTerminalHandoff.cpp" />
Create Telnet connection type and default loopback profile for… (#3858) For our Universal terminal for development purposes, we will use telnet to escape the universal application container and empower developers to debug/diagnose issues with their own machine on loopback to the already-elevated telnet context.
2019-12-09 20:07:08 +01:00
<ClCompile Include="init.cpp" />
Switch Connections to use `ValueSet`s to initialize them (#10184) #### ⚠️ targets #10051 ## Summary of the Pull Request This PR does one big, primary thing. It removes all the constructors from any TerminalConnections, and changes them to use an `Initialize` method that accepts a `ValueSet` of properties. Why? For the upcoming window/content process work, we'll need the content process to be able to initialize the connection _in the content process_. However, the window process will be the one that knows what type of connection to make. Enter `ConnectionInformation`. This class will let us specify the class name of the type we want to create, and a set of settings to use when initializing that connection. **IMPORTANT**: As a part of this, the constructor for a connection must have 0 arguments. `RoActivateInstance` lets you just conjure a WinRT type just by class name, but that class must have a 0 arg ctor. Hence the need for `Initialize`, to actually pass the settings. We're using a `ValueSet` here because it's basically a json blob, with more steps. In the future, when extension authors want to have custom connections, we can always deserialize the json into a `ValueSet`, pass it to their connection's `Initialize`, and let then get what they need out of it. ## References * Tear-out: #1256 * Megathread: #5000 * Project: https://github.com/microsoft/terminal/projects/5 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760298 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments `ConnectionInformation` was included as a part of this PR, to demonstrate how this will eventually be used. `ConnectionInformation` is not _currently_ used. ## Validation Steps Performed It still builds and runs.
2021-07-20 17:02:17 +02:00
<ClCompile Include="ConnectionInformation.cpp">
<DependentUpon>ConnectionInformation.idl</DependentUpon>
</ClCompile>
Create Telnet connection type and default loopback profile for… (#3858) For our Universal terminal for development purposes, we will use telnet to escape the universal application container and empower developers to debug/diagnose issues with their own machine on loopback to the already-elevated telnet context.
2019-12-09 20:07:08 +01:00
<ClCompile Include="AzureConnection.cpp">
<DependentUpon>AzureConnection.idl</DependentUpon>
</ClCompile>
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
<ClCompile Include="pch.cpp">
<PrecompiledHeader>Create</PrecompiledHeader>
</ClCompile>
<ClCompile Include="EchoConnection.cpp">
<DependentUpon>EchoConnection.idl</DependentUpon>
</ClCompile>
Replace ConhostConnection with ConptyConnection (#3461) This commit deletes ConhostConnection and replaces it with ConptyConnection. The ConptyConnection uses CreatePseudoConsole and depends on winconpty to override the one from kernel32. * winconpty must be packageable, so I've added GetPackagingOutputs. * To validate this, I added conpty.dll to the MSIX regression script. * I moved the code from conpty-universal that deals with environment strings into the types library. This puts us in a way better place to implement #2563, as we can now separately detect a failure to launch a pseudoconsole, a failure to CreateProcess, and an unexpected termination of the launched process. Fixes #1131.
2019-11-07 00:09:01 +01:00
<ClCompile Include="ConptyConnection.cpp">
<DependentUpon>ConptyConnection.idl</DependentUpon>
</ClCompile>
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
<ClCompile Include="$(GeneratedFilesDir)module.g.cpp" />
</ItemGroup>
<ItemGroup>
Switch Connections to use `ValueSet`s to initialize them (#10184) #### ⚠️ targets #10051 ## Summary of the Pull Request This PR does one big, primary thing. It removes all the constructors from any TerminalConnections, and changes them to use an `Initialize` method that accepts a `ValueSet` of properties. Why? For the upcoming window/content process work, we'll need the content process to be able to initialize the connection _in the content process_. However, the window process will be the one that knows what type of connection to make. Enter `ConnectionInformation`. This class will let us specify the class name of the type we want to create, and a set of settings to use when initializing that connection. **IMPORTANT**: As a part of this, the constructor for a connection must have 0 arguments. `RoActivateInstance` lets you just conjure a WinRT type just by class name, but that class must have a 0 arg ctor. Hence the need for `Initialize`, to actually pass the settings. We're using a `ValueSet` here because it's basically a json blob, with more steps. In the future, when extension authors want to have custom connections, we can always deserialize the json into a `ValueSet`, pass it to their connection's `Initialize`, and let then get what they need out of it. ## References * Tear-out: #1256 * Megathread: #5000 * Project: https://github.com/microsoft/terminal/projects/5 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760298 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments `ConnectionInformation` was included as a part of this PR, to demonstrate how this will eventually be used. `ConnectionInformation` is not _currently_ used. ## Validation Steps Performed It still builds and runs.
2021-07-20 17:02:17 +02:00
<Midl Include="ConnectionInformation.idl" />
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
<Midl Include="ITerminalConnection.idl" />
Replace ConhostConnection with ConptyConnection (#3461) This commit deletes ConhostConnection and replaces it with ConptyConnection. The ConptyConnection uses CreatePseudoConsole and depends on winconpty to override the one from kernel32. * winconpty must be packageable, so I've added GetPackagingOutputs. * To validate this, I added conpty.dll to the MSIX regression script. * I moved the code from conpty-universal that deals with environment strings into the types library. This puts us in a way better place to implement #2563, as we can now separately detect a failure to launch a pseudoconsole, a failure to CreateProcess, and an unexpected termination of the launched process. Fixes #1131.
2019-11-07 00:09:01 +01:00
<Midl Include="ConptyConnection.idl" />
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
<Midl Include="EchoConnection.idl" />
Azure connector only shows up if available (#2195) The default azure connector profile only shows up if a) its a release build and b) its non-ARM64 Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2019-08-02 23:41:46 +02:00
<Midl Include="AzureConnection.idl" />
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
</ItemGroup>
<ItemGroup>
Change exit code to hex; Fix format spec (#11123) Process exit code now shows as hex not decimal. Format specification needs length "10" not "8" because the leading '0x' generated by the # symbol counts as part of the length. ## PR Checklist * [x] Closes annoyance at looking up process exit codes * [x] I work here. * [x] Checked manually ## Validation Steps Performed - [x] Ran it, opened tab, opened another CMD tab, ran `exit <code>` and observed hex pattern
2021-09-21 17:47:17 +02:00
<PRIResource Include="Resources\en-US\Resources.resw">
<SubType>Designer</SubType>
</PRIResource>
Move all wildcards into targets or expand them (#6406) Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must be generated by targets. We mostly use wildcards for pulling in PRI files that are dumped on disk by the translation tool. We don't want to check those in, so we can't expand references to them. To that end, I've introduced a new target that will take a list of folders containing resw files and expand wildcards under them. All[1] other wildcards have been moved into their respective targets _or_ simply expanded. [1]: Nothing has complained about the resource wildcards in CascadiaResources.build.items, so I haven't exploded it yet. Fixes #6214.
2020-06-08 23:01:47 +02:00
<OCResourceDirectory Include="Resources" />
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
<None Include="packages.config" />
</ItemGroup>
set identifying environment variable for new connections (#897) * set identifying environment variable for new connections Set a new 'WT_SESSION' environment variable when creating new terminal connections to allow shells to detect a unique Windows Terminal session. The value of the variable is a stringified GUID as returned by CoCreateGuid. How verified: - "razzle" & vs debug build - runut - manual inspection * * use winrt::guid type for connection guid * use Utils::GuidToString for guid stringification * expose guid parameter in ITerminalConnection idl * - poke guid through ITerminalConnection - misc. review fixes - throw if CreateConPty fails in ConhostConnection::Start - apply [[nodiscard]] and noexcept in various places * - simplify environment variable extraction in UpdateEnvironmentMapW * - use Utils::CreateGuid instead of CoCreateGuid in ConHostConnection()
2019-05-22 22:24:22 +02:00
<!-- ========================= Project References ======================== -->
<ItemGroup>
<!--
the packaging project won't recurse through our dependencies, you have to
make sure that if you add a cppwinrt dependency to any of these projects,
you also update all the consumers
-->
<ProjectReference Include="$(OpenConsoleDir)src\types\lib\types.vcxproj">
<Project>{18D09A24-8240-42D6-8CB6-236EEE820263}</Project>
</ProjectReference>
Move AzureConnection's strings into localizable resources (#3463) This also sets up TerminalConnection to _have_ resources, which will be useful for the messages in #3461.
2019-11-07 21:26:45 +01:00
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\WinRTUtils\WinRTUtils.vcxproj">
<Project>{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
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
<ProjectReference Include="..\..\winconpty\lib\winconptylib.vcxproj">
Replace ConhostConnection with ConptyConnection (#3461) This commit deletes ConhostConnection and replaces it with ConptyConnection. The ConptyConnection uses CreatePseudoConsole and depends on winconpty to override the one from kernel32. * winconpty must be packageable, so I've added GetPackagingOutputs. * To validate this, I added conpty.dll to the MSIX regression script. * I moved the code from conpty-universal that deals with environment strings into the types library. This puts us in a way better place to implement #2563, as we can now separately detect a failure to launch a pseudoconsole, a failure to CreateProcess, and an unexpected termination of the launched process. Fixes #1131.
2019-11-07 00:09:01 +01:00
<Project>{58a03bb2-df5a-4b66-91a0-7ef3ba01269a}</Project>
</ProjectReference>
set identifying environment variable for new connections (#897) * set identifying environment variable for new connections Set a new 'WT_SESSION' environment variable when creating new terminal connections to allow shells to detect a unique Windows Terminal session. The value of the variable is a stringified GUID as returned by CoCreateGuid. How verified: - "razzle" & vs debug build - runut - manual inspection * * use winrt::guid type for connection guid * use Utils::GuidToString for guid stringification * expose guid parameter in ITerminalConnection idl * - poke guid through ITerminalConnection - misc. review fixes - throw if CreateConPty fails in ConhostConnection::Start - apply [[nodiscard]] and noexcept in various places * - simplify environment variable extraction in UpdateEnvironmentMapW * - use Utils::CreateGuid instead of CoCreateGuid in ConHostConnection()
2019-05-22 22:24:22 +02:00
</ItemGroup>
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
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.post.props" />
replace vcpkg-cpprestsdk with a +ARM64 -ssl/boost +UWP version (#3489) This new cpprestsdk package, 2.10.14, switches us to the app CRT. cpprestsdk turns fof a bunch of boost and openssl dependencies when it's built for the Windows Store subplatform, so we got a bunch of stuff for free. Incidentally, I fixed #2338 the real/correct way -- the build rules in the package now make sure they're not using the system vcpkg root.
2019-11-08 23:17:11 +01:00
<Import Project="..\..\..\packages\vcpkg-cpprestsdk.2.10.14\build\native\vcpkg-cpprestsdk.targets" Condition="Exists('..\..\..\packages\vcpkg-cpprestsdk.2.10.14\build\native\vcpkg-cpprestsdk.targets')" />
The Azure cloud shell connector (#1808) * We can now connect to the Azure cloud shell #1235
2019-07-25 22:31:41 +02:00
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
replace vcpkg-cpprestsdk with a +ARM64 -ssl/boost +UWP version (#3489) This new cpprestsdk package, 2.10.14, switches us to the app CRT. cpprestsdk turns fof a bunch of boost and openssl dependencies when it's built for the Windows Store subplatform, so we got a bunch of stuff for free. Incidentally, I fixed #2338 the real/correct way -- the build rules in the package now make sure they're not using the system vcpkg root.
2019-11-08 23:17:11 +01:00
<Error Condition="!Exists('..\..\..\packages\vcpkg-cpprestsdk.2.10.14\build\native\vcpkg-cpprestsdk.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\..\packages\vcpkg-cpprestsdk.2.10.14\build\native\vcpkg-cpprestsdk.targets'))" />
The Azure cloud shell connector (#1808) * We can now connect to the Azure cloud shell #1235
2019-07-25 22:31:41 +02:00
</Target>
Replace ConhostConnection with ConptyConnection (#3461) This commit deletes ConhostConnection and replaces it with ConptyConnection. The ConptyConnection uses CreatePseudoConsole and depends on winconpty to override the one from kernel32. * winconpty must be packageable, so I've added GetPackagingOutputs. * To validate this, I added conpty.dll to the MSIX regression script. * I moved the code from conpty-universal that deals with environment strings into the types library. This puts us in a way better place to implement #2563, as we can now separately detect a failure to launch a pseudoconsole, a failure to CreateProcess, and an unexpected termination of the launched process. Fixes #1131.
2019-11-07 00:09:01 +01:00
<ItemDefinitionGroup>
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
<ClCompile>
Change exit code to hex; Fix format spec (#11123) Process exit code now shows as hex not decimal. Format specification needs length "10" not "8" because the leading '0x' generated by the # symbol counts as part of the length. ## PR Checklist * [x] Closes annoyance at looking up process exit codes * [x] I work here. * [x] Checked manually ## Validation Steps Performed - [x] Ran it, opened tab, opened another CMD tab, ran `exit <code>` and observed hex pattern
2021-09-21 17:47:17 +02:00
<AdditionalIncludeDirectories>$(IntDir)..\OpenConsoleProxy;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
</ClCompile>
Replace ConhostConnection with ConptyConnection (#3461) This commit deletes ConhostConnection and replaces it with ConptyConnection. The ConptyConnection uses CreatePseudoConsole and depends on winconpty to override the one from kernel32. * winconpty must be packageable, so I've added GetPackagingOutputs. * To validate this, I added conpty.dll to the MSIX regression script. * I moved the code from conpty-universal that deals with environment strings into the types library. This puts us in a way better place to implement #2563, as we can now separately detect a failure to launch a pseudoconsole, a failure to CreateProcess, and an unexpected termination of the launched process. Fixes #1131.
2019-11-07 00:09:01 +01:00
<Link>
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
<AdditionalDependencies>$(OpenConsoleCommonOutDir)\conptylib.lib;%(AdditionalDependencies)</AdditionalDependencies>
Replace ConhostConnection with ConptyConnection (#3461) This commit deletes ConhostConnection and replaces it with ConptyConnection. The ConptyConnection uses CreatePseudoConsole and depends on winconpty to override the one from kernel32. * winconpty must be packageable, so I've added GetPackagingOutputs. * To validate this, I added conpty.dll to the MSIX regression script. * I moved the code from conpty-universal that deals with environment strings into the types library. This puts us in a way better place to implement #2563, as we can now separately detect a failure to launch a pseudoconsole, a failure to CreateProcess, and an unexpected termination of the launched process. Fixes #1131.
2019-11-07 00:09:01 +01:00
</Link>
</ItemDefinitionGroup>
Move all wildcards into targets or expand them (#6406) Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must be generated by targets. We mostly use wildcards for pulling in PRI files that are dumped on disk by the translation tool. We don't want to check those in, so we can't expand references to them. To that end, I've introduced a new target that will take a list of folders containing resw files and expand wildcards under them. All[1] other wildcards have been moved into their respective targets _or_ simply expanded. [1]: Nothing has complained about the resource wildcards in CascadiaResources.build.items, so I haven't exploded it yet. Fixes #6214.
2020-06-08 23:01:47 +02:00
<Import Project="$(SolutionDir)build\rules\CollectWildcardResources.targets" />
Fix for missing CopyComplete files in TerminalConnection.vcxproj (#11804) I'm working on making the FastUpToDate check in Vs work for the Terminal project. This is one of a few PRs in this area. FastUpToDate lets vs check quickly determine that it doesn't need to do anything for a given project. However, a few of our projects don't produce all the right artifacts, or check too many things, and this eventually causes the `wapproj` to rebuild, EVERY TIME YOU F5 in VS. This first PR deals with the `.copycomplete` file in `obj\x64\debug\terminalconnection\`. Below are my verbatim notes, which led to the solution in this PR. ### Problem 1 ✅ * There were missing `.copycomplete` files across the repo. ``` obj\x64\debug\microsoft.terminal.settings.model.lib\microsoft.terminal.settings.modellib.vcxproj.copycomplete obj\x64\debug\microsoft.terminal.settings.model\microsoft.terminal.settings.model.vcxproj.copycomplete obj\x64\debug\terminalapplib\terminalapplib.vcxproj.copycomplete obj\x64\debug\terminalapp\terminalapp.vcxproj.copycomplete obj\x64\debug\terminalconnection\terminalconnection.vcxproj.copycomplete ``` - just making empty files there seemed good enough. - Might be because the CopyLocal target was already there, but the task didn't ever run to create that file? Weird. * UPDATE: checking out main, and building again - the `.copycomplete`s are gone. So that's something that can be improved. * The only place I could find a reference was in `"obj\x64\Debug\TerminalConnection\TerminalConnection.vcxproj.FileListAbsolute.txt"`, which will get updated if you remove the line from that file (but no one seemingly writes it or mentiones it in the log) * Deleting `bin\x64\Debug\TerminalConnection\cpprest142_2_10d.dll` then building the project did copy the file, but it didn't touch the copycomplete. Weird. * Why does - `TerminalConnection` think it needs this - `Microsoft.Terminal.Settings.Model.Lib` have one - `Microsoft.Terminal.Control*` **NOT** have one * This file is a [`@(CopyUpToDateMarker)`](https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.CurrentVersion.targets#L392) * The target [`_CopyFilesMarkedCopyLocal`](https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.CurrentVersion.targets#L4795) touches `@(CopyUpToDateMarker)`, when: - `"'@(ReferencesCopiedInThisBuild)' != ''` and - `'$(WroteAtLeastOneFile)' == 'true'"` * In out build output: ``` 6>Target _CopyFilesMarkedCopyLocal: 6> Using "Copy" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". 6> Task "Copy" 6> Did not copy from file "C:\Users\migrie\dev\public\terminal\bin\x64\Debug\TerminalConnection\cpprest142_2_10d.dll" to file "C:\Users\migrie\dev\public\terminal\bin\x64\Debug\TerminalConnection\cpprest142_2_10d.dll" because the "SkipUnchangedFiles" parameter was set to "true" in the project and the files' sizes and timestamps match. 6> Done executing task "Copy". 6> Task "Touch" skipped, due to false condition; ('@(ReferencesCopiedInThisBuild)' != '' and '$(WroteAtLeastOneFile)' == 'true') was evaluated as ('C:\Users\migrie\dev\public\terminal\bin\x64\Debug\TerminalConnection\cpprest142_2_10d.dll' != '' and 'False' == 'true'). ``` - So `WroteAtLeastOneFile` should be true, when it's currently false. That _looks_ like it's set to true when the file does get copied, wheich did't happen because the copy was skipped. - WAIT LOOK AT THAT MESSAGE. "Did not copy from file " `"C:\Users\migrie\dev\public\terminal\bin\x64\Debug\TerminalConnection\cpprest142_2_10d.dll"` to file `"C:\Users\migrie\dev\public\terminal\bin\x64\Debug\TerminalConnection\cpprest142_2_10d.dll"` THESE ARE THE SAME FILE. `@(ReferenceCopyLocalPaths)` is filled with the file already?! - The Target `AppLocalFromInstalled` is the only other thing that references `cpprest142_2_10d.dll`. - Even if you delete the `cpprest142_2_10d.dll`, then `_CopyFilesMarkedCopyLocal` still evaluates the Touch condition as false, and doesn't touch it. - the `deployBinary()` function in `packages\vcpkg-cpprestsdk.2.10.14\scripts\buildsystems\msbuild\applocal.ps1` does the actual job of copying the file. It copies it outside of MsBuild, which prevents MsBuild from copying it, and now MsBuild thinks it shouldn't write the `.copycomplete` file itself.
2021-11-23 12:51:45 +01:00
<!--
BODGY:
We depend on `cpprest142*.dll`, which comes from our vcpkg dependency. As a
part of the vcpkg dependency restore, msbuild will call the `deployBinary()`
function in
`packages\vcpkg-cpprestsdk.2.10.14\scripts\BuildSystems\msbuild\AppLocal.ps1`.
That function does the actual job of copying the file. It copies it outside of
MsBuild. MsBuild then, in the `_CopyFilesMarkedCopyLocal` target, determines
that it needs to copy `cpprest142*.dll`, because that dll is a member of
`@(ReferencesCopiedInThisBuild)`. However, the file's already been copied, so
MsBuild never copies it. But that also prevents MsBuild from setting
`WroteAtLeastOneFile`, which then means that MsBuild will never create the
.CopyComplete file for this project.
Because that file is missing, MsBuild will never think the project is up to
date, and the FastUpToDate check in VS will always force MsBuild to run a pass
on this project.
To mitigate this, we're adding this other target here, which runs after
_CopyFilesMarkedCopyLocal, and always creates the CopyUpToDateMarker. This
makes the FastUpToDate check succeed.
-->
<Target
Name="_Post_CopyFilesMarkedCopyLocal"
AfterTargets="_CopyFilesMarkedCopyLocal"
Condition="'@(ReferenceCopyLocalPaths)' != ''">
<Touch Files="@(CopyUpToDateMarker)"
AlwaysCreate="true" />
</Target>
</Project>
Reference in a new issue Copy permalink