Refactor pure C++ types from TerminalApp.dll into a lib

[zadjii-msft]

Right now we have one big dll that is declaring both cppwinrt types (e.g. AppKeyBindings, App) and pure c++ types (Tab, Profile, etc.).

If one were to try and create a unittesting project for the TerminalApp project, you unfortunately would be unable to do this, because many of the types are only linked into this TerminalApp.dll. For pure cppwinrt types, this isn't that big of a deal, because instantiating the types just does cppwinrt magic to activate them. However, for pure cpp classes, we can't actually link them. This means we can't test things like json parsing, Pane recursing, settings synthesis.

So we'll have to pull all the types that aren't winrt types out into their own lib, and have the TerminalApp project consume that lib.

I'm not worried about TermControl and TermConnection so much, since those are only using cppwinrt types at the moment. Should they get more elaborate, then it might be necessary to do a similar refactoring.

Worries:

1. Does this mean we're going to have now two pch.pch files for the TerminalApp, one for the lib and one for the dll? could we avoid that? See Share PCH files #946.
2. The lib seems to need to include winrt/coroutine.h (and any other cppwinrt headers that components might need). Those are generated files. Right now they're generated by the TerminalApp(dll) build, but theoretically they'll need to be created before that, because the lib will theoretically be built before the dll. This may mean that the lib needs to have some sort of cppwinrt tooling turned on, but I don't know what quite yet.

[zadjii-msft]

@DHowett-MSFT I'm pulling the triage tag on this one since we've discussed this in chat.

[DHowett-MSFT]

There should definitely not be two pch files -- the dll should exist solely and exclusively to turn the lib into a dll. There's probably some stupidity regarding making sure every .obj from the lib is actually included in the dll though, because the linker loves to remove things it thinks nobody can see.

[zadjii-msft]

Also @Scottj1s because he might be curious.

[zadjii-msft]

Oh there's even more insanity here.

TerminalApp depends on 4 other cppwinrt projects:

• TerminalSettings, TerminalControl, and Microsoft.UI.Xaml.Markup (MUX.Markup) are all projects in our solution
• Microsoft.UI.Xaml is a project we're including from nuget. It's included in the build as a Reference paired with a ReferenceCopyLocalPaths

If you try to move all the types to the lib, you're going to have a bad day. You're going to need to make the lib project a cppwinrt project, but it'll be ConfigurationType=StaticLibrary. If you make it a cppwinrt project, it's somehow unable to find the winmd's from the projects it references. They're all DynamicLibrary projects, so presumably they'd be found by <Target Name="GetCppWinRTDynamicWinMDReferences" in the cppwinrt targets, but they somehow aren't found at all.

The actual error is:

2>C:\Users\migrie\dev\private\OpenConsole\src\cascadia\TerminalApp\lib\App.idl(9): error MIDL2011: 
[msg]unresolved type declaration [context]: Microsoft.UI.Xaml.Markup.XamlApplication [ RuntimeClass 'TerminalApp.App'  ]

Which suggests it can't find the MUX.Markup winmd. This is true, it can't:

2>Target GetCppWinRTStaticProjectReferences:
2>  Task "Message"
2>    CppWinRTStaticProjectReferences: C:\Users\migrie\dev\private\OpenConsole\bin\x64\Debug\ConTypes.lib
2>  Done executing task "Message".
2>Target GetCppWinRTStaticWinMDReferences:
2>  Task "Message"
2>    CppWinRTStaticWinMDReferences: C:\Users\migrie\dev\private\OpenConsole\bin\x64\Debug\Microsoft.Terminal.TerminalControl.winmd
2>  Done executing task "Message".
2>Target "ResolvedLinkLib" skipped. Previously built successfully.
2>Target GetCppWinRTDynamicProjectReferences:
2>  Task "Message"
2>    CppWinRTDynamicProjectReferences:
2>  Done executing task "Message".
2>Target GetCppWinRTDynamicWinMDReferences:
2>  Task "Message"
2>    CppWinRTDynamicWinMDReferences:
2>  Done executing task "Message".
2>Target "ResolveAssemblyReferences" skipped. Previously built successfully.
2>Target GetCppWinRTDirectWinMDReferences:
2>  Task "Message"
2>    CppWinRTDirectWinMDReferences: C:\Users\migrie\dev\private\OpenConsole\packages\Microsoft.UI.Xaml.2.1.190405001-prerelease\lib\uap10.0\Microsoft.UI.Xaml.winmd
2>  Done executing task "Message".

Actually more insane, is that the project does seem to find the TerminalControl winmd, but not the TerminalSettings or MUX.Markup ones. If you inspect the midlrt.rsp file, you'll see

/reference "C:\Users\migrie\dev\private\OpenConsole\packages\Microsoft.UI.Xaml.2.1.190405001-prerelease\lib\uap10.0\Microsoft.UI.Xaml.winmd"
/reference "C:\Users\migrie\dev\private\OpenConsole\bin\x64\Debug\Microsoft.Terminal.TerminalControl.winmd"

at the top of the file.

So that's where I'm at with this.

[zadjii-msft]

Okay my earlier comment about TerminalControl was misguided - somehow a rouge Microsoft.Terminal.TerminalControl.winmd found its way to my bin/ folder. So it was automagically getting included when it shouldn't have been. This might clear up some of the insanity I was having.