UnigramDev/Unigram/develop • f1a180b • 1 files, +49/-10
The first numbers that come from the app itself

.NET Native Release, one cold start on the pointer path: 15,431 updates,
25.0 MB, 0.25s of TDLib-thread time, 3.25% of an 8s startup.

Two things the corpus could not have said. The parse runs at 151 MB/s against
the benchmark's 377 for a payload of that size - same parser, same toolchain,
but a growing heap and a real mix of updates rather than one payload in a loop,
so the corpus number is a ceiling and it is 2.4x above what the app sees.

And the file existence checks did not get faster when everything around them
did: 109 us in Debug against 74 here, while the parse dropped 3.4x. That is
I/O and an AppContainer check rather than codegen, so they cannot be made
cheaper - only rarer or asynchronous. They were 11% of the thread's parse work
in Debug and are 34% of it now, and that share grows as the parser improves.

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

UnigramDev/Unigram/develop • 7c5ac15 • 2 files, +142/-17
Deploy and run the .NET 10 build under its own identity

It starts, and this is the first time any of it has run: registered as
38833FF26BA1D.UnigramNet10, "Unigram .NET 10", beside UnigramExperimental and the
store package rather than over either of them. A separate package family means a
separate LocalState, so the port cannot touch a real account.

The identity is patched into a copy of Package.appxmanifest in obj\ rather than
kept as a second manifest - three XmlPokes against 108 lines of capabilities,
extensions and file associations that would otherwise drift. The destination has
to come from BaseIntermediateOutputPath: IntermediateOutputPath is still empty
where it evaluates, which collapses the copy onto the source and rewrites the real
manifest in place, as it did once. Hence the Error guard in that target.

Content needs CopyToOutputDirectory. The legacy project system deployed Content
implicitly and SDK-style does not, with nothing said at build time: the first run
initialised TDLib, wrote its databases, and then died on

XamlParseException: Cannot locate resource from 'ms-appx:///Common/CommonStyles.xaml'

because neither that file nor anything under Assets\ had been laid down. Assets\**
is auto-included by the MSIX tooling, so it takes Content Update, not a second
Include.

Packaging also wanted EnableMsixTooling rather than a bare AppxPackage (the PRI
targets are otherwise half-configured and fail on IntermediateExtension), no
explicit PRIResource items (the SDK globs the .resw itself, and listing them too
is NETSDK1022), and the C++/WinRT binaries copied by hand, since projections are
not ProjectReferences and nothing else brings them along.

net10-port-todo.md carries the deploy and launch recipe, and where to read a crash:
the app's own ErrorReports json says what the event log's 0xc000027b will not.

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

#unigram