Add a Scratch.sln for prototyping (#10067)
#### ⚠️ This targets #10051
## Summary of the Pull Request
This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.
While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.
* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
- It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.
Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).
## Validation Steps Performed
The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>
(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
2021-06-10 19:49:12 +02:00
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets= "Build" ToolsVersion= "15.0" xmlns= "http://schemas.microsoft.com/developer/msbuild/2003" >
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.props" Condition= "Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.3\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.props')" />
Add a Scratch.sln for prototyping (#10067)
#### ⚠️ This targets #10051
## Summary of the Pull Request
This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.
While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.
* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
- It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.
Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).
## Validation Steps Performed
The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>
(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
2021-06-10 19:49:12 +02:00
<PropertyGroup Label= "Globals" >
<ProjectGuid > {b4427499-9fde-4208-b456-5bc580637633}</ProjectGuid>
<Keyword > Win32Proj</Keyword>
<RootNamespace > WindowExe</RootNamespace>
<ProjectName > WindowExe</ProjectName>
<TargetName > WindowExe</TargetName>
<ConfigurationType > Application</ConfigurationType>
<OpenConsoleUniversalApp > false</OpenConsoleUniversalApp>
<ApplicationType > Windows Store</ApplicationType>
<WindowsStoreApp > true</WindowsStoreApp>
<WindowsAppContainer > false</WindowsAppContainer>
<TargetPlatformIdentifier > Windows</TargetPlatformIdentifier>
</PropertyGroup>
<Import Project= "..\..\..\common.openconsole.props" Condition= "'$(OpenConsoleDir)'==''" />
<Import Project= "$(OpenConsoleDir)src\cppwinrt.build.pre.props" />
<ItemDefinitionGroup >
<ClCompile >
<SDLCheck > true</SDLCheck>
</ClCompile>
</ItemDefinitionGroup>
<ItemDefinitionGroup >
<ClCompile >
<AdditionalIncludeDirectories > $(OpenConsoleDir)\src\inc;$(OpenConsoleDir)\dep;$(OpenConsoleDir)\dep\Console;$(OpenConsoleDir)\dep\Win32K;$(OpenConsoleDir)\dep\gsl\include;%(AdditionalIncludeDirectories);</AdditionalIncludeDirectories>
</ClCompile>
<Link >
<AdditionalDependencies > %(AdditionalDependencies)</AdditionalDependencies>
</Link>
</ItemDefinitionGroup>
<PropertyGroup >
<GenerateManifest > true</GenerateManifest>
<EmbedManifest > true</EmbedManifest>
</PropertyGroup>
<!-- Source Files -->
<ItemGroup >
<ClInclude Include= "pch.h" />
<ClInclude Include= "icon.h" />
<ClInclude Include= "resource.h" />
<ClInclude Include= "SampleAppHost.h" />
<ClInclude Include= "SampleBaseWindow.h" />
<ClInclude Include= "SampleIslandWindow.h" />
</ItemGroup>
<ItemGroup >
<ClCompile Include= "pch.cpp" >
<PrecompiledHeader > Create</PrecompiledHeader>
</ClCompile>
<ClCompile Include= "icon.cpp" />
<ClCompile Include= "SampleMain.cpp" />
<ClCompile Include= "SampleAppHost.cpp" />
<ClCompile Include= "SampleIslandWindow.cpp" />
</ItemGroup>
<ItemGroup >
<ResourceCompile Include= "WindowExe.rc" />
</ItemGroup>
<ItemGroup >
<Manifest Include= "WindowExe.manifest" />
</ItemGroup>
<ItemGroup >
<None Include= "packages.config" />
</ItemGroup>
<!-- ========================= Project References ======================== -->
<ItemGroup >
<ProjectReference Include= "$(OpenConsoleDir)scratch\ScratchIslandApp\SampleApp\dll\SampleApp.vcxproj" />
</ItemGroup>
<!-- ========================== Other References ========================= -->
<ItemGroup >
<!--
!! LOAD BEARING !!
Make sure these winmd's are all Private=true,
CopyLocalSatelliteAssemblies=true, at this layer. Those will force the
packaging project to actually include those winmd's in our final package. If
they're missing, then WinRT will have a hard time marshalling those types
across a process boundary.
Particularly tricky is Microsoft.Terminal.Core.winmd. That winmd doesn't
have its own DLL (it doesn't have any activatable classes, only structs and
interfaces). However, it too is necessary for Terminal.Control to be able to
marshall the Core types across the boundary.
-->
<Reference Include= "Microsoft.Terminal.Core" >
<HintPath > $(OpenConsoleCommonOutDir)TerminalCore\Microsoft.Terminal.Core.winmd</HintPath>
<IsWinMDFile > true</IsWinMDFile>
<Private > true</Private>
<CopyLocalSatelliteAssemblies > true</CopyLocalSatelliteAssemblies>
</Reference>
<Reference Include= "Microsoft.Terminal.TerminalConnection" >
<HintPath > $(OpenConsoleCommonOutDir)TerminalConnection\Microsoft.Terminal.TerminalConnection.winmd</HintPath>
<Implementation > $(OpenConsoleCommonOutDir)TerminalConnection\TerminalConnection.dll</Implementation>
<IsWinMDFile > true</IsWinMDFile>
<Private > true</Private>
<CopyLocalSatelliteAssemblies > true</CopyLocalSatelliteAssemblies>
</Reference>
<Reference Include= "Microsoft.Terminal.Control" >
<HintPath > $(OpenConsoleCommonOutDir)Microsoft.Terminal.Control\Microsoft.Terminal.Control.winmd</HintPath>
<Implementation > $(OpenConsoleCommonOutDir)Microsoft.Terminal.Control\Microsoft.Terminal.Control.dll</Implementation>
<IsWinMDFile > true</IsWinMDFile>
<Private > true</Private>
<CopyLocalSatelliteAssemblies > true</CopyLocalSatelliteAssemblies>
</Reference>
</ItemGroup>
<!--
This ItemGroup and the Globals PropertyGroup below it are required in order
to enable F5 debugging for the unpackaged application
-->
<ItemGroup >
<PropertyPageSchema Include= "$(VCTargetsPath)$(LangID)\debugger_general.xml" />
<PropertyPageSchema Include= "$(VCTargetsPath)$(LangID)\debugger_local_windows.xml" />
</ItemGroup>
<PropertyGroup Label= "Globals" >
<DebuggerFlavor > WindowsLocalDebugger</DebuggerFlavor>
</PropertyGroup>
Fixes the wapproj fast-up-to-date check (#11806)
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 third PR deals with the Actual fast up to date check for the CascadiaPackage.wapproj. When #11804, #11805 and this PR are all merged, you should be able to just F5 the Terminal in VS, and then change NOTHING, and F5 it again, without doing a build at all.
The wapproj `GetResolvedWinMD` target tries to get a winmd from every cppwinrt
executable we put in the package. But we DON'T produce a winmd. This makes the
FastUpToDate check fail every time, and leads to the whole wapproj build
running even if you're just f5'ing the package. EVEN AFTER A SUCCESSFUL BUILD.
Setting GenerateWindowsMetadata=false is enough to tell the build system that
we don't produce one, and get it off our backs.
### teams chat where we figured this out
[3:38 PM] Dustin Howett
however, that's not the only thing that "GetTargetPath" checks.
[3:38 PM] Dustin Howett
oh yeah more info: wapproj calls GetTargetPath on all projects it references
[3:38 PM] Dustin Howett
when it calls GTP on WindowsTerminal.vcxproj it is getting back a winmd (!)
[3:39 PM] Dustin Howett
here's the magic
[3:39 PM] Dustin Howett
[3:39 PM] Dustin Howett
it checks if any Link items specify GenerateWindowsMetadata
2021-11-23 12:22:56 +01:00
<!--
BODGY
The wapproj `GetResolvedWinMD` target tries to get a winmd from every cppwinrt
executable we put in the package. But we DON'T produce a winmd. This makes the
FastUpToDate check fail every time, and leads to the whole wapproj build
running even if you're just f5'ing the package. EVEN AFTER A SUCCESSFUL BUILD.
Setting GenerateWindowsMetadata=false is enough to tell the build system that
we don't produce one, and get it off our backs.
-->
<ItemDefinitionGroup >
<Link >
<GenerateWindowsMetadata > false</GenerateWindowsMetadata>
</Link>
</ItemDefinitionGroup>
Add a Scratch.sln for prototyping (#10067)
#### ⚠️ This targets #10051
## Summary of the Pull Request
This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.
While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.
* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
- It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.
Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).
## Validation Steps Performed
The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>
(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
2021-06-10 19:49:12 +02:00
<Import Project= "$(OpenConsoleDir)src\cppwinrt.build.post.props" />
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')" />
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 Scratch.sln for prototyping (#10067)
#### ⚠️ This targets #10051
## Summary of the Pull Request
This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.
While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.
* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
- It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.
Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).
## Validation Steps Performed
The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>
(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
2021-06-10 19:49:12 +02:00
<Import Project= "..\..\..\packages\Microsoft.VCRTForwarders.140.1.0.4\build\native\Microsoft.VCRTForwarders.140.targets" Condition= "Exists('..\..\..\packages\Microsoft.VCRTForwarders.140.1.0.4\build\native\Microsoft.VCRTForwarders.140.targets')" />
<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>
2021-09-21 00:08:55 +02:00
<Error Condition= "!Exists('..\..\..\packages\Microsoft.UI.Xaml.2.7.0-prerelease.210913003\build\native\Microsoft.UI.Xaml.targets')" Text= "$([System.String]::Format('$(ErrorText)', '..\..\..\packages\Microsoft.UI.Xaml.2.7.0-prerelease.210913003\build\native\Microsoft.UI.Xaml.targets'))" />
2021-07-13 00:58:02 +02:00
<Error Condition= "!Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.3\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.props')" Text= "$([System.String]::Format('$(ErrorText)', '..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.3\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.props'))" />
<Error Condition= "!Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.3\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets')" Text= "$([System.String]::Format('$(ErrorText)', '..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.3\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets'))" />
Add a Scratch.sln for prototyping (#10067)
#### ⚠️ This targets #10051
## Summary of the Pull Request
This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.
While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.
* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
- It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.
Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).
## Validation Steps Performed
The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>
(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
2021-06-10 19:49:12 +02:00
<Error Condition= "!Exists('..\..\..\packages\Microsoft.VCRTForwarders.140.1.0.4\build\native\Microsoft.VCRTForwarders.140.targets')" Text= "$([System.String]::Format('$(ErrorText)', '..\..\..\packages\Microsoft.VCRTForwarders.140.1.0.4\build\native\Microsoft.VCRTForwarders.140.targets'))" />
</Target>
<!-- Override GetPackagingOutputs to roll up all our dependencies.
This ensures that when the WAP packaging project asks what files go into
the package, we tell it.
This is a heavily stripped version of the one in Microsoft.*.AppxPackage.targets.
-->
<PropertyGroup >
<_ContinueOnError Condition= "'$(BuildingProject)' == 'true'" > true</_ContinueOnError>
<_ContinueOnError Condition= "'$(BuildingProject)' != 'true'" > false</_ContinueOnError>
</PropertyGroup>
<Target Name= "GetPackagingOutputs" Returns= "@(PackagingOutputs)" >
<MSBuild
Projects="@(ProjectReferenceWithConfiguration)"
Targets="GetPackagingOutputs"
BuildInParallel="$(BuildInParallel)"
Properties="%(ProjectReferenceWithConfiguration.SetConfiguration); %(ProjectReferenceWithConfiguration.SetPlatform)"
Condition="'@(ProjectReferenceWithConfiguration)' != ''
and '%(ProjectReferenceWithConfiguration.BuildReference)' == 'true'
and '%(ProjectReferenceWithConfiguration.ReferenceOutputAssembly)' == 'true'"
ContinueOnError="$(_ContinueOnError)">
<Output TaskParameter= "TargetOutputs" ItemName= "_PackagingOutputsFromOtherProjects" />
</MSBuild>
<ItemGroup >
<PackagingOutputs Include= "@(_PackagingOutputsFromOtherProjects)" />
</ItemGroup>
<!-- **BEGIN VC LIBS HACK** -->
<PropertyGroup >
<ReasonablePlatform Condition= "'$(Platform)'=='Win32'" > x86</ReasonablePlatform>
<ReasonablePlatform Condition= "'$(ReasonablePlatform)'==''" > $(Platform)</ReasonablePlatform>
</PropertyGroup>
<ItemGroup Condition= "'$(WindowExeOfficialBuild)'=='true'" >
<!-- Add all the CRT libs as content; these must be inside a Target as they are wildcards. -->
<_OpenConsoleVCLibToCopy Include= "$(VCToolsRedistInstallDir)\$(ReasonablePlatform)\Microsoft.VC142.CRT\*.dll" />
<PackagingOutputs Include= "@(_OpenConsoleVCLibToCopy)" >
<ProjectName > $(ProjectName)</ProjectName>
<OutputGroup > BuiltProjectOutputGroup</OutputGroup>
<TargetPath > %(Filename)%(Extension)</TargetPath>
</PackagingOutputs>
</ItemGroup>
<!-- **END VC LIBS HACK** -->
<!-- **BEGIN TERMINAL CONNECTION HACK** -->
<!-- This is the same as the above VC libs hack, but for TerminalConnection.
TerminalConnection depends on cpprest*.dll, and if we don't include it in
the packaging output, we'll crash as soon as we try to load
TerminalConnection.dll.
The Sample sln needs to do this manually - the real exe has a
ProjectReference to TerminalConnection.vcxproj and can figure this out on
its own. -->
<ItemGroup >
<_TerminalConnectionDlls Include= "$(OpenConsoleCommonOutDir)\TerminalConnection\*.dll" />
<PackagingOutputs Include= "@(_TerminalConnectionDlls)" >
<ProjectName > $(ProjectName)</ProjectName>
<OutputGroup > BuiltProjectOutputGroup</OutputGroup>
<TargetPath > %(Filename)%(Extension)</TargetPath>
</PackagingOutputs>
</ItemGroup>
<!-- **END TERMINAL CONNECTION HACK** -->
<!-- Same thing again here, with WindowsTerminal.exe -->
<ItemGroup >
<_WindowsTerminalExe Include= "$(OpenConsoleCommonOutDir)\WindowsTerminal\*.exe" />
<PackagingOutputs Include= "@(_WindowsTerminalExe)" >
<ProjectName > $(ProjectName)</ProjectName>
<OutputGroup > BuiltProjectOutputGroup</OutputGroup>
<TargetPath > %(Filename)%(Extension)</TargetPath>
</PackagingOutputs>
</ItemGroup>
</Target>
<Import Project= "$(OpenConsoleDir)\build\rules\GenerateSxsManifestsFromWinmds.targets" />
<Import Project= "..\..\..\packages\Terminal.ThemeHelpers.0.2.200324001\build\native\Terminal.ThemeHelpers.targets" Condition= "Exists('..\..\..\packages\Terminal.ThemeHelpers.0.2.200324001\build\native\Terminal.ThemeHelpers.targets')" />
</Project>
