Zac Gaetano
8e29c1dc1e
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.
110 lines
5.4 KiB
XML
110 lines
5.4 KiB
XML
<Project Sdk="Microsoft.NET.Sdk">
|
|
|
|
<!--
|
|
TeamsISO WinUI 3 host. Coexists with the WPF project (src/TeamsISO.App)
|
|
during the redesign migration. Shares the engine (TeamsISO.Engine) and
|
|
the NDI interop assembly via ProjectReference. Once the WinUI 3 build is
|
|
feature-complete and tested against a real Teams meeting, the WPF
|
|
project is retired and this becomes the only shipping host.
|
|
|
|
Target framework choice: net8.0-windows10.0.19041.0 is the minimum the
|
|
Windows App SDK supports cleanly. Going higher (e.g. 22621) would lock
|
|
out Win10 1809+ operators, which is undesirable for a broadcast tool
|
|
that still has to run on hardware in working broadcast suites.
|
|
|
|
Packaging mode: WindowsPackageType=None for "unpackaged" — the .exe
|
|
drops directly into Program Files via the existing MSI rather than
|
|
going through MSIX. The Windows App Runtime install becomes a prereq
|
|
of the MSI (or bootstrapped at startup), which matches how operators
|
|
install NDI Runtime today.
|
|
-->
|
|
<PropertyGroup>
|
|
<OutputType>WinExe</OutputType>
|
|
<TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
|
|
<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
|
|
<SupportedOSPlatformVersion>10.0.17763.0</SupportedOSPlatformVersion>
|
|
<RootNamespace>TeamsISO.App.WinUI</RootNamespace>
|
|
<AssemblyName>TeamsISO</AssemblyName>
|
|
<!--
|
|
Default app.manifest deferred: WinUI 3 emits its own manifest with the
|
|
DPI awareness + supportedOS GUIDs that match what we want. Our custom
|
|
manifest (kept in tree at app.manifest) describes the same intent but
|
|
doesn't currently merge cleanly with the framework-emitted manifest;
|
|
see docs/superpowers/plans/2026-05-12-winui3-migration.md for the
|
|
follow-up to reintroduce it via uap:VisualElements.
|
|
-->
|
|
<Platforms>x64;ARM64</Platforms>
|
|
<RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
|
|
<UseWinUI>true</UseWinUI>
|
|
<WindowsPackageType>None</WindowsPackageType>
|
|
<EnableMsixTooling>true</EnableMsixTooling>
|
|
<!--
|
|
Pinning the Windows SDK projection package: WindowsAppSDK 1.6 requires
|
|
Microsoft.Windows.SDK.NET.Ref >= 10.0.19041.38, but the .NET 8.0.301
|
|
SDK installed here ships an older Ref. Setting this explicitly avoids
|
|
having to upgrade the .NET SDK on the build host.
|
|
-->
|
|
<WindowsSdkPackageVersion>10.0.19041.38</WindowsSdkPackageVersion>
|
|
<!--
|
|
Disable the XAML compiler's auto-generated Program.Main so we can write
|
|
one that bootstraps the Windows App Runtime explicitly. The default
|
|
generated Main calls Application.Start directly, with no Bootstrap
|
|
initialization step — that's fine for packaged MSIX apps but blocks
|
|
unpackaged launch on a machine where the runtime is installed only as
|
|
a framework package. Program.cs in this project takes ownership of
|
|
Main and calls Bootstrap.TryInitialize(0x00010006) before Start.
|
|
-->
|
|
<DefineConstants>$(DefineConstants);DISABLE_XAML_GENERATED_MAIN</DefineConstants>
|
|
<!--
|
|
RuntimeIdentifier locks the build to win-x64 so runtime DLLs from
|
|
runtimes/win-x64/native (Microsoft.WindowsAppRuntime.Bootstrap.dll,
|
|
WebView2Loader.dll) flatten into the output dir alongside the .exe.
|
|
Without this, those DLLs sit in runtimes/win-x64/native/ and the
|
|
loader doesn't find them at activation time.
|
|
-->
|
|
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
|
|
<!--
|
|
Suppress the auto-injected UndockedRegFreeWinRT ModuleInitializer.
|
|
The bundled initializer P/Invokes Microsoft.WindowsAppRuntime.dll
|
|
during module load, BEFORE our Program.Main has a chance to call
|
|
Bootstrap.TryInitialize. Since the runtime DLL lives in the framework
|
|
MSIX package (not the output dir) on a framework-dependent install,
|
|
the P/Invoke fails to locate it and the .exe dies with the generic
|
|
"this application could not be started" dialog — diagnosed by
|
|
following the Microsoft.WindowsAppSDK.UndockedRegFreeWinRT.CS.targets
|
|
chain and reading the auto-init source. Our Program.cs handles the
|
|
bootstrap explicitly in the right order.
|
|
-->
|
|
<WindowsAppSdkUndockedRegFreeWinRTInitialize>false</WindowsAppSdkUndockedRegFreeWinRTInitialize>
|
|
<Nullable>enable</Nullable>
|
|
<ImplicitUsings>enable</ImplicitUsings>
|
|
<ApplicationIcon>Assets\teamsiso.ico</ApplicationIcon>
|
|
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
|
|
</PropertyGroup>
|
|
|
|
<!--
|
|
WindowsAppSDK 1.6 is the current LTS branch (Win10 1809-compatible at
|
|
a 10.0.17763 floor, which matches our SupportedOSPlatformVersion).
|
|
DataGrid lives in the older 7.x Community Toolkit because the 8.x line
|
|
dropped it; 7.1.2 still works on WinUI 3 / WindowsAppSDK 1.6 and is the
|
|
only currently-maintained free DataGrid for this stack.
|
|
-->
|
|
<ItemGroup>
|
|
<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.6.250602001" />
|
|
<PackageReference Include="CommunityToolkit.WinUI.UI.Controls.DataGrid" Version="7.1.2" />
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<ProjectReference Include="..\TeamsISO.Engine\TeamsISO.Engine.csproj" />
|
|
<ProjectReference Include="..\TeamsISO.Engine.NdiInterop\TeamsISO.Engine.NdiInterop.csproj" />
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<Content Include="Assets\teamsiso.ico" />
|
|
<Content Include="Assets\dragon-mark.png" />
|
|
<Content Include="Assets\wild-dragon-wordmark.png" />
|
|
<Content Include="Assets\Fonts\Inter.ttf" />
|
|
<Content Include="Assets\Fonts\JetBrainsMono.ttf" />
|
|
</ItemGroup>
|
|
|
|
</Project>
|