Before this change, the pchs for CalcViewModel and Calculator project referenced project headers. If those project headers (or any of their dependencies) were to change, then the pch would be recompiled, slowing local build times.
By removing references to project headers, the pch will be compiled once and is resilient to changes in the project. Now that project headers are explicit about their dependencies, when there is a change to a project header only the translation units referencing the modified header will need to be rebuilt.
- Manually tested by ensuring Calculator project builds locally.
@Microsoft/calculator-team
Update the Microsoft.UI.Xaml NuGet package to a new version. The ARM64 framework package in 2.0.181018003.1 had entries missing from its manifest, so the classes in the package couldn't be activated.
The app currently logs diagnostic events to ETW in various places. If we add certain flags to those events, the data is eligible to be sent as telemetry. (Whether it actually gets sent is controlled outside of Calculator--for example, there are lots of checks at the system level to ensure privacy settings are honored.)
Currently we set the "eligible for telemetry" flags only in official builds, so no telemetry gets uploaded while the app is in development. We already have this set up for the main TraceLogging provider, but we also need to do this for the AppLifecycle performance logging.
Calculator (the main app project) depends on CalcManager, but only transitively: Calculator -> CalcViewModel -> CalcManager.
However, Calculator's project file currently has a direct dependency on CalcManager. Let's remove this to make it harder to accidentally introduce new dependencies between the layers.
Also cleaning up some commented-out directives in the CalcManager MSBuild file.
A few small changes to improve the view of the code in Solution Explorer:
* Delete folders from solution explorer which don't appear on disk (Resource Files, PerfTrack)
* Delete files on disk which aren't compiled into the project (Type.xaml)
* Rename CalculatorHistory.Cpp to CalculatorHistory.cpp, for consistency with other files
Remove LayoutAwarePage, SuspensionManager, and other suspend-resume handling code. SuspensionManager::SaveAsync and related methods weren't actually called anywhere. I didn't attempt to remove the serialize/deserialize code at the ViewModel layer, although much of that is likely not needed either.
We may decide we want to persist more state through a suspend-terminate-resume cycle (as the app might have done a long time ago). But if we decide we want that, we should not use a persistence mechanism that's closely coupled to frame navigation.
