Add a Scratch.sln for prototyping

[zadjii-msft]

⚠️ 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: Add support for tab tearoff and tab merge #1256
• Megathread: Scenario: Windows Terminal 2.0 Process Model Improvements #5000
• Project: https://github.com/microsoft/terminal/projects/5

PR Checklist

• Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
• I work here
• 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 ctrl+p menu cough).

Validation Steps Performed

The sample app launches, and displays a TermControl. What else do you want? ^{(rhetorical, not a prompt for a wishlist)}

[DHowett]

notes from 1:1 - samples is reserved for applications that demonstrate how to use console APIs; @zadjii-msft was not upset at the idea of moving this sample

[ghost]

Hello @miniksa!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[carlos-zamora]

Urgh. This is something super minor (and late), but any chance we can move Scratch.sln to be somewhere else? Maybe under samples.

Didn't want to open a new issue for a minor inconvenience of mine haha.

[DHowett]

@carlos-zamora you can move it into scratch/ itself if you like, you just have to edit all of the project paths inside of it.

[DHowett]

Does having two SLN files in the root of the repo mess up some tools? Sorry, we didn't even consider...

[carlos-zamora]

Does having two SLN files in the root of the repo mess up some tools? Sorry, we didn't even consider...

Nah, this is just a personal pet peeve haha. I have this in my PowerShell $profile:

Function Open-Solution
{
    $repo_root = git rev-parse --show-toplevel
    Invoke-Item $repo_root\*.sln
}

So now it'll always open OpenConsole.sln and Scratch.sln.

That said, I feel like Scratch.sln being at the root is a bit out of place imo.

[DHowett]

out of place

I agree. Take action!