UnigramDev/Unigram/develop • e41087d • 2 files, +25/-0
Two experimental build settings for the packaging path

ShouldUnsetParentConfigurationAndPlatform on the packaging project, so Telegram is compiled
once rather than twice. Building a solution or building in Visual Studio defaults it to true,
which drops Configuration and Platform from the globals used to build the referenced projects;
Microsoft.AppXPackage.Targets then asks the same projects for GetPackagingOutputs with both set
explicitly. MSBuild keys its cache on path plus global properties, so that is a second instance
and a second full build, the first against Telegram.csproj's own default platform of x86.

A Release x64 bundle built with it produces one compile and one .NET Native pass, but there is
no comparison run without it, and it has only been exercised from the command line rather than
the packaging wizard. Telegram.Stub is what to watch: the solution deliberately maps it away
from the parent platform, and that mapping is what unsetting the parent configuration was for.

DisableFastUpToDateCheck on the app, against the stale generated XAML. Visual Studio's own
heuristic decides whether to invoke MSBuild at all and does not track the generated files well,
so a .g.cs can end up older than the .xaml it came from and the build compiles yesterday's
generated code against today's source. SendFilesPopup.g.cs was 17 hours behind its .xaml and
only deleting obj cleared it. This trades a second or two per up to date build for asking
MSBuild rather than guessing.

Both are marked experimental in the files themselves, with what to watch for and what to revert.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • b2784a4 • 1 files, +62/-15
Give the benchmark README a resume point

The findings had grown past the point where the state of the work was findable in
them, and the Open list still named things that are done. Adds "Where this
stands" - what is finished, the four steps to put the pointer parsers in the app,
what is open independently - and a section of traps worth not re-learning, the
first of which is that every wrong conclusion in this file came from comparing
numbers taken in different runs on a machine that varies 1.8x.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 1be32c9 • 1 files, +99/-0
Write down where the native dependency work stands

Resume point for the vcpkg manifest move and the switch to prebuilt libvlc and webrtc: what is
pinned and why, what is verified against what is not, what is left in order, and the traps that
cost time to find the first time.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram