Adds <WindowsAppSdkUndockedRegFreeWinRTInitialize>false</...> with a
comment chain that traces the runtime activation failure investigation
to the next maintainer:
1. WindowsAppSDK's UndockedRegFreeWinRTCommon.targets only auto-enables
the ModuleInitializer when WindowsAppSDKSelfContained=true.
2. Without it, framework-dependent unpackaged builds need our own
explicit Bootstrap.TryInitialize call (Program.cs already does this).
3. WITH it, the bundled auto-init P/Invokes Microsoft.WindowsAppRuntime.dll
during module load — but the runtime DLL lives in the framework MSIX
package, not the output dir, and Bootstrap hasn't yet added the
framework dir to the DLL search path. The P/Invoke fails and the
.exe dies before Main runs.
Setting the property to false explicitly suppresses the early P/Invoke
so our Program.Main + Bootstrap.TryInitialize can sequence correctly.
This didn't fix activation on this build host though — the .exe still
shows "this application could not be started." Strong suspicion: the
managed assembly references Microsoft.WinUI.dll which itself has
DllImport-style dependencies the .NET host probes during assembly load.
Recommended next steps (not done overnight to avoid further blind
swings): attach a debugger to TeamsISO.exe before Main runs (windbg
sxe ld for the runtime DLL, or VS 'Just My Code: off' attach), capture
the CLR fusion log, or try a known-good Microsoft WinUI 3 template
side-by-side to isolate whether the issue is project or machine.
Build remains clean. WPF host unaffected.
Locks RuntimeIdentifier=win-x64 so MSBuild flattens the WindowsAppSDK
native runtime files (Microsoft.WindowsAppRuntime.Bootstrap.dll +
WebView2Loader.dll, both in runtimes/win-x64/native/) directly alongside
TeamsISO.exe at build time, instead of leaving them in a runtimes/
subfolder where the loader can't find them at activation.
Also defers app.manifest from build pending the bootstrapper hardening
follow-up. WinUI 3 emits its own manifest with the DPI awareness +
supportedOS GUIDs that match what we want; reintroducing ours alongside
that needs a uap:VisualElements merge.
Build is clean. Activation still blocked on a separate WinUI 3
unpackaged-launch issue that doesn't reach Main(); diagnostics
captured in COREHOST_TRACE=1 confirm .NET host loads correctly through
CoreCLR.dll, the failure is downstream in the WinUI / WindowsAppSDK
activation path.
The WPF host remains the running build until the activation issue is
resolved.
Lands the approved shape brief as the WinUI 3 MainWindow:
* 64px left rail with brand mark, primary nav (participants), Teams
launch / hide / settings buttons, and the engine-status puck at the
bottom. All five rail buttons use Segoe Fluent Icons glyphs at a
uniform 20px optical size; no more bespoke <Path Data> shapes with
inconsistent stroke weights.
* 44px custom title bar via ExtendsContentIntoTitleBar +
SetTitleBar(AppTitleBar). The drag region absorbs the three live-state
pills inline (session timer 'live * 00:14:32', REC count + elapsed,
disk free) and a slim sun/moon theme-toggle button to the left of the
system Min/Max/Close controls. System buttons inherit ButtonForeground
Color etc. from AppWindow.TitleBar so they match palette in both
themes.
* Section header with 'Participants * count' display, filter input,
Refresh + Presets (Secondary buttons), and 'Enable all online' as
the single cyan Primary button - finally a real button hierarchy
instead of seven indistinguishable ghost buttons.
* Participants list rendered as ItemsRepeater + DataTemplate for now;
the CommunityToolkit DataGrid migration follows in a separate commit.
Row template at 64px height with: 3px cyan left border for active
speaker, avatar with initials in cyan-muted circle, name + codec line,
signal lock state with dot, audio meter via ProgressBar, output name
in JetBrains Mono, ISO state pill (LIVE/OFF/ERROR) at right.
* Conditional in-call control bar below the table: Mute / Camera /
Share / Marker / Leave + overflow kebab. Muted state binds the
destructive coral treatment to the Mute button; Leave is also
destructive (coral border + text); everything else is Secondary.
Tight 8px spacing keeps the bar dense without crowding.
* Slim 32px status bar at the bottom: control-surface URL on the left
(cyan dot indicator), keyboard-shortcut hints on the right in
tertiary mono. Replaces the WPF host's six-column footer.
Implementation notes:
* MockParticipant model populates the table with representative data
(Maya / Daniel / Aicha / Sam, one as active speaker) until the
ParticipantViewModel binding migrates over from the WPF host.
* Custom Program.cs takes ownership of Main from the XAML compiler
(DISABLE_XAML_GENERATED_MAIN). Calls Bootstrap.TryInitialize(0x00010006)
before Application.Start so the unpackaged .exe can locate the
WindowsAppSDK 1.6 framework MSIX at launch. Shutdown is paired in
a finally block.
* Theme toggle in code-behind flips Window.Content.RequestedTheme
between Dark and Light. {ThemeResource} bindings auto-swap across
the visual tree; system title-bar buttons (outside the XAML tree)
get color updates inline so they stay readable in both modes.
* app.manifest deferred from build - the framework-emitted manifest
covers DPI awareness and supportedOS GUIDs; reintroducing our own
goes in the next commit alongside the bootstrapper hardening.
Known issue: the unpackaged .exe currently fails to activate on this
build host with 'this application could not be started' before Main
runs. Build is clean; published output runs the same way. Diagnosing
the activation failure is the next session's first task (likely the
runtimeconfig.json including Microsoft.WindowsDesktop.App which WinUI 3
doesn't want, or a missing CRT redistributable). The WPF host remains
the running build until that's resolved.
dotnet build TeamsISO.Windows.slnf -c Debug: 0 warnings, 0 errors.
First step of the WinUI 3 replatform per the approved redesign brief.
The new project coexists with the existing src/TeamsISO.App (WPF) so the
WPF host keeps building and shipping while the WinUI 3 redesign lands
incrementally. Once the WinUI 3 build is feature-complete and tested
against a real Teams meeting, the WPF project is retired.
Scaffold contents:
* src/TeamsISO.App.WinUI/TeamsISO.App.WinUI.csproj
Windows App SDK 1.6 LTS (250602001), unpackaged mode
(WindowsPackageType=None) so the existing MSI installer keeps working.
Target framework net8.0-windows10.0.19041.0, min platform 10.0.17763.0
to preserve Win10 1809+ compatibility for working broadcast hardware.
Pins WindowsSdkPackageVersion=10.0.19041.38 so .NET SDK 8.0.301 builds
cleanly without an SDK upgrade on the build host.
* src/TeamsISO.App.WinUI/app.manifest
PerMonitorV2 DPI awareness + gdiScaling for crisp text on high-DPI
broadcast monitors. asInvoker trust level (control surface :9755 and
OSC :9000 bind to 127.0.0.1, no admin needed).
* App.xaml + App.xaml.cs
Minimal startup: brings up MainWindow. The full pipeline (NDI runtime
preflight, IsoController wiring, single-instance mutex, REST + OSC
bridge, tray icon, crash diagnostics, auto-update banner, onboarding)
migrates in subsequent commits.
* Themes/Tokens.xaml
Wild Dragon design tokens as ThemeDictionary entries (Default = Dark,
Light). Colors as Color resources, Brushes paired per theme so
{ThemeResource} auto-swaps when RequestedTheme flips — no app restart,
no flicker. Spacing/radii/typography tokens are theme-agnostic at the
outer level. Light palette maintains brand recognition via cyan-tinted
off-whites (#FAFAFB canvas, #F0F1F3 rail) rather than pure white, and
splits cyan into accent.cyan.surface (#97EDF0, works in both modes
because text on top is near-black) and accent.cyan.text (#97EDF0 dark
/ #0E7C82 light) so captions and inline labels keep AA contrast.
* Themes/Controls.xaml
Button hierarchy with real commitments: Primary (cyan fill, one per
surface), Secondary (transparent bordered), Tertiary (text only),
Destructive (coral border + text), Caption (titlebar), RailIcon.
Typographic ramp (Display / Title / Heading / Body / Subtle / Caption
/ Mono) at the DESIGN.md 1.25 ratio.
* CommunityToolkit.WinUI.UI.Controls.DataGrid 7.1.2 referenced for the
participants table migration. (Toolkit 8.x dropped DataGrid; 7.x is
the only currently-maintained free option for WinUI 3.)
* Inter.ttf + JetBrainsMono.ttf + dragon-mark.png + teamsiso.ico copied
from the WPF project's Assets/ so the WinUI 3 host is self-contained.
* TeamsISO.sln + TeamsISO.Windows.slnf updated to include the new
project. The .slnf paths switch to backslash form so MSBuild can match
them against the .sln's canonical path representation.
Verified: dotnet build TeamsISO.Windows.slnf -c Debug succeeds with 0
warnings and 0 errors for all 8 projects (WPF host, WinUI 3 host, engine,
NDI interop, console, three test projects).
