Split the sample out of the backend lane; make PublicAPI ownership real

An MSBuild review found two merge blockers. Both were reproduced before
being fixed, and the fixes are mutation-tested.

1. The real sample compiled nothing.

   TizenPackage.props defaults EnableDefaultCompileItems to false, since
   most projects here still hold raw imported sources that do not build
   yet. The sample never opted back in, so it evaluated Compile=[] - an
   application head that built successfully while containing no code,
   produced no entry point, and demonstrated nothing. Confirmed with
   `dotnet msbuild -getItem:Compile`, which returned an empty array.

   Its four sources were instead compiled inside the backend ref-pack
   lane. That type-checked them but merged them into one Core+sample
   assembly, so the package boundary the sample exists to demonstrate
   was never crossed: a sample reaching for a backend internal, or for
   anything invisible across an assembly reference, compiled clean.

   The sample now globs its own sources, as a real Tizen app head does,
   and a new tests/Maui.Tizen.Sample.RefPackCompile compiles it as its
   own assembly with a ProjectReference to the backend lane - which now
   carries the real product AssemblyName, so the reference reproduces
   what a package consumer sees rather than a lane-shaped substitute.

2. PublicAPI ownership was false-green.

   With one merged compilation and both baseline pairs attached, either
   baseline satisfied either assembly. Moving
   Microsoft.Maui.Platforms.Tizen.TizenFlyoutView out of the backend
   baseline and into the SAMPLE's still built successfully - verified.
   Each lane now sees only its own baseline; that same mutation fails
   RS0016, and dropping a sample entry fails RS0016 in the sample lane,
   confirming the analyzer is genuinely live in both.

Validation-gap fixes requested with the blockers:

- The ref-pack-only PLATFORM define was already removed in 8b06927; it
  is now pinned by an evaluated-property assertion rather than csproj
  text.

- Guards that grepped Sources.props are converted to EVALUATED MSBuild
  items via a shared MSBuildEvaluation helper. Text matching answered a
  different question than the one asked: the props file carries a
  supersession comment naming every file it documents, so deleting a
  real Compile item left the comment behind. Evaluation also follows
  imports, conditions and item removals, which text cannot.

- ProjectEvaluationTests computed AdditionalFiles, assigned it to a
  discard, then asserted on raw csproj text - proving only that two
  strings appeared in the file. It now asserts what MSBuild evaluated.

TizenFX reference wiring moved to eng/targets/TizenRefPack.targets so
both lanes reference an identical TizenFX; the boundary between them
proves nothing otherwise.

Mutations confirmed caught: deleting a compile item; reverting the
sample to EnableDefaultCompileItems=false; re-absorbing the sample into
the backend lane; re-attaching the sample baseline to the backend lane;
moving a Core API into the sample baseline (fast guard and RS0016).

Validation: 280 host tests (was 270) Debug and Release; 42 foundation
tests; both ref-pack lanes build Release against real TizenFX with the
PublicAPI analyzer enabled and no RS0016/RS0017; full workload-free gate
passes and now covers the sample lane. The real sample still cannot be
built - it targets net11.0-tizen11.0 and is blocked on the Samsung
workload - and nothing has been run on a device.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: e23a54a9-6a68-4e30-8920-e2a17fd2ad6a

Author: Redth

Maui.Tizen.slnx

@@ -30,6 +30,7 @@
     <Project Path="tests/UnitTests/Maui.Tizen.UnitTests.csproj" />
     <Project Path="tests/Maui.Tizen.Core.UnitTests/Maui.Tizen.Core.UnitTests.csproj" />
     <Project Path="tests/Maui.Tizen.Core.RefPackCompile/Maui.Tizen.Core.RefPackCompile.csproj" />
+    <Project Path="tests/Maui.Tizen.Sample.RefPackCompile/Maui.Tizen.Sample.RefPackCompile.csproj" />
     <Project Path="eng/tests/PackageGraphProbe/PackageGraphProbe.csproj" />
     <Project Path="eng/tests/PublicApiOptIn/PublicApiOptIn.csproj" />
     <Project Path="eng/tests/PackReadmeProbe/PackReadmeProbe.csproj" />

docs/net11-status.md

@@ -15,15 +15,33 @@ until Samsung publishes the 11.0.100 workload manifest (see blocker B1). Rather
 contract with a neutral fallback, verification is split across two **complementary** lanes. They do
 not compile identical sets - that would be impossible, since the platform sources need real TizenFX:
 
-| Lane | Compiles | `TIZEN` defined |
-| --- | --- | --- |
-| `Maui.Tizen.Core.UnitTests` | portable + handler | no |
-| `Maui.Tizen.Core.RefPackCompile` | portable + handler + platform + sample | yes |
-| `Maui.Tizen.Core` (product) | portable + handler + platform | yes |
+| Lane | Compiles | Assembly | `TIZEN` |
+| --- | --- | --- | --- |
+| `Maui.Tizen.Core.UnitTests` | portable + handler | test host | no |
+| `Maui.Tizen.Core.RefPackCompile` | portable + handler + platform | `Maui.Tizen.Core` | yes |
+| `Maui.Tizen.Sample.RefPackCompile` | sample only, references the above | `Maui.Tizen.Sample` | yes |
+| `Maui.Tizen.Core` (product) | portable + handler + platform | `Maui.Tizen.Core` | yes |
 
 Between them every owned source is compiled by at least one lane, and everything the product
 compiles is also compiled by the ref-pack lane. `SourceLaneCoverageTests` pins that invariant.
 
+The sample gets its **own** lane rather than being folded into the backend's, and that separation is
+load-bearing in two ways an MSBuild review had to point out:
+
+* The sample must cross a real assembly boundary. Compiled into the backend lane it produced one
+  merged Core+sample assembly, so a sample that reached for a backend internal - or for anything
+  invisible across a package reference - compiled clean. It now reaches the backend through a
+  `ProjectReference` to an assembly carrying the real product `AssemblyName`.
+* PublicAPI ownership is only meaningful while each compilation is checked against its own baseline.
+  With both pairs attached to one merged surface, moving `TizenFlyoutView` out of the backend
+  baseline and into the *sample's* still built successfully. It now fails RS0016.
+
+The real `samples/Maui.Tizen.Sample` separately evaluated `Compile=[]` - `TizenPackage.props`
+defaults `EnableDefaultCompileItems` to false for the not-yet-ported projects and the sample never
+opted back in, so it was an application head that built successfully while containing no code.
+`PackageBoundaryTests` asserts the evaluated item lists of the real sample and its lane are
+identical, so neither can drift from the other.
+
 | Lane | Command | What it proves |
 | --- | --- | --- |
 | Unit tests | `dotnet test tests/Maui.Tizen.Core.UnitTests` | Mapper + command-mapper registration, DI/handler registration, hosting, dispatcher/timer/provider semantics, density conversion, layout z-index ordering, `IMauiContext` scoping. **102 tests, all passing.** |

eng/build-workload-free.sh

@@ -133,11 +133,19 @@ WORKLOAD_FREE_PROJECTS=(
   #                               (mapper and DI registration, hosting, dispatching, density,
   #                               layout z-index ordering).
   #
-  #   Maui.Tizen.Core.RefPackCompile  type-checks every `#if TIZEN` source, and the sample
-  #                               head, against the REAL TizenFX reference assemblies from
-  #                               Samsung.Tizen.Ref.API15. It is compile-only and unpackable,
-  #                               so it cannot become a neutral fallback for the product.
+  #   Maui.Tizen.Core.RefPackCompile  type-checks every `#if TIZEN` backend source against the
+  #                               REAL TizenFX reference assemblies from Samsung.Tizen.Ref.API15,
+  #                               and enforces the backend's PublicAPI baseline. Compile-only and
+  #                               unpackable, so it cannot become a neutral fallback.
+  #
+  #   Maui.Tizen.Sample.RefPackCompile  compiles the sample head as its OWN assembly with a
+  #                               ProjectReference to the backend, so the sample crosses a real
+  #                               package boundary. It used to be folded into the backend lane,
+  #                               which merged both into one assembly and meant the boundary was
+  #                               never actually exercised - and left PublicAPI ownership
+  #                               unverifiable, since either baseline satisfied either assembly.
   "tests/Maui.Tizen.Core.RefPackCompile/Maui.Tizen.Core.RefPackCompile.csproj"
+  "tests/Maui.Tizen.Sample.RefPackCompile/Maui.Tizen.Sample.RefPackCompile.csproj"
   "tests/Maui.Tizen.Core.UnitTests/Maui.Tizen.Core.UnitTests.csproj"
 
   # Foundation-owned probes.

eng/targets/TizenRefPack.targets

@@ -0,0 +1,46 @@
+<Project>
+
+  <!--
+    Shared TizenFX reference-assembly wiring for the workload-free compile lanes.
+
+    The product targets net11.0-tizen11.0 and cannot be restored until Samsung publishes the
+    11.0.100 workload manifest (blocker B1). Samsung.Tizen.Ref.API15 does however ship real
+    ref/net8.0 reference assemblies for the whole of TizenFX, so the Tizen-only sources can still
+    be type-checked on a plain net11.0 host.
+
+    This lives in its own file because there are now TWO lanes that need it - one for the backend
+    and one for the sample - and they must reference an identical TizenFX or the boundary between
+    them proves nothing.
+  -->
+
+  <ItemGroup>
+    <!--
+      PackageDownload rather than PackageReference: these packages publish no net11.0-compatible
+      assets, so a normal reference fails restore with NU1202. We only want the files on disk.
+    -->
+    <PackageDownload Include="$(TizenReferencePackId)" Version="[$(TizenReferencePackVersion)]" />
+    <PackageDownload Include="Tizen.UIExtensions.NUI" Version="[$(TizenUIExtensionsPackageVersion)]" />
+  </ItemGroup>
+
+  <Target Name="_AddTizenReferenceAssemblies" BeforeTargets="ResolveAssemblyReferences">
+    <PropertyGroup>
+      <_TizenRefPackDir>$(NuGetPackageRoot)$(TizenReferencePackId.ToLowerInvariant())/$(TizenReferencePackVersion)/ref/net8.0/</_TizenRefPackDir>
+      <_TizenUIExtensionsDir>$(NuGetPackageRoot)tizen.uiextensions.nui/$(TizenUIExtensionsPackageVersion)/lib/tizen10.0/</_TizenUIExtensionsDir>
+    </PropertyGroup>
+
+    <Error Condition="!Exists('$(_TizenRefPackDir)Tizen.NUI.dll')"
+           Code="MAUITIZEN0102"
+           Text="Could not find Tizen.NUI.dll under '$(_TizenRefPackDir)'. Expected it from $(TizenReferencePackId) $(TizenReferencePackVersion); run 'dotnet restore' for this project first." />
+
+    <ItemGroup>
+      <Reference Include="$(_TizenRefPackDir)Tizen.NUI.dll" Private="false" />
+      <Reference Include="$(_TizenRefPackDir)Tizen.NUI.Components.dll" Private="false" />
+      <Reference Include="$(_TizenRefPackDir)Tizen.Applications.Common.dll" Private="false" />
+      <Reference Include="$(_TizenRefPackDir)Tizen.Applications.UI.dll" Private="false" />
+      <Reference Include="$(_TizenRefPackDir)Tizen.Log.dll" Private="false" />
+      <Reference Include="$(_TizenRefPackDir)Tizen.dll" Private="false" />
+      <Reference Include="$(_TizenUIExtensionsDir)Tizen.UIExtensions.NUI.dll" Private="false" Condition="Exists('$(_TizenUIExtensionsDir)Tizen.UIExtensions.NUI.dll')" />
+    </ItemGroup>
+  </Target>
+
+</Project>

samples/Maui.Tizen.Sample/Maui.Tizen.Sample.csproj

@@ -37,6 +37,23 @@
     <IsPackable>false</IsPackable>
     <GenerateDocumentationFile>false</GenerateDocumentationFile>
     <Nullable>enable</Nullable>
+
+    <!--
+      TizenPackage.props defaults EnableDefaultCompileItems to FALSE, because most projects in this
+      repository still hold raw imported dotnet/maui sources that do not compile yet and are listed
+      as <None> so they stay navigable.
+
+      The sample is not one of those. It is four hand-written files, all of which compile. Without
+      this opt-in it evaluated Compile=[] - an application head that built successfully while
+      containing no code at all, produced no entry point, and silently proved nothing. Verified with
+      `dotnet msbuild -getItem:Compile`, which returned an empty array.
+
+      Default globbing rather than an explicit list, because that is what a real Tizen app head
+      does and this project's job is to look like one. The ref-pack sample lane compiles the same
+      files from @(MauiTizenSampleCompile); RealSampleCompilesItsOwnSources and
+      SampleLaneCompilesExactlyTheRealSamplesSources pin the two sets together so neither can drift.
+    -->
+    <EnableDefaultCompileItems>true</EnableDefaultCompileItems>
   </PropertyGroup>
 
 

tests/Maui.Tizen.Core.RefPackCompile/Maui.Tizen.Core.RefPackCompile.csproj

@@ -1,20 +1,32 @@
 <Project Sdk="Microsoft.NET.Sdk">
 
   <!--
-    Compile-validation lane.
+    Backend compile-validation lane.
 
     The product assembly targets net11.0-tizen11.0 and cannot be restored until Samsung publishes
     the 11.0.100 workload manifest. That would normally leave every NUI-touching source file in this
-    repository completely unverified.
-
-    Samsung.Tizen.Ref.API15 does, however, ship real `ref/net8.0` reference assemblies for the whole
-    of TizenFX. This project pulls them down with PackageDownload (which skips NuGet's TFM
-    compatibility check) and compiles the backend's Tizen-only sources against them with TIZEN
-    defined, on a plain net11.0 host.
+    repository completely unverified. This project compiles the backend's Tizen-only sources against
+    the real TizenFX reference assemblies with TIZEN defined, on a plain net11.0 host.
 
     This is NOT a neutral fallback for the product - it produces no shippable output
     (IsPackable=false, reference-only assemblies, never executed). It exists purely so `#if TIZEN`
     code is type-checked in CI instead of being taken on faith.
+
+    SCOPE: backend sources ONLY.
+
+    This lane used to compile the sample's sources too. That was wrong in two ways, both of which a
+    review caught:
+
+      * It produced a single merged Core+sample assembly, so the sample never actually crossed the
+        package boundary it exists to demonstrate. A sample that touched an internal, or a type it
+        could not see through a real assembly reference, would have compiled clean here.
+      * The analyzer saw one merged public surface with both baseline pairs attached, so PublicAPI
+        ownership was false-green: moving a Core type into the SAMPLE's baseline still passed.
+        Verified by mutation - Microsoft.Maui.Platforms.Tizen.TizenFlyoutView was moved into the
+        sample baseline and the build still succeeded.
+
+    The sample is now compiled by tests/Maui.Tizen.Sample.RefPackCompile, which reaches this
+    assembly through a ProjectReference exactly as a package consumer would.
   -->
 
   <Import Project="$(RepositoryRoot)eng/Maui.props" />
@@ -23,7 +35,14 @@
   <PropertyGroup>
     <TargetFramework>$(DotNetTfm)</TargetFramework>
     <IsTizenProject>false</IsTizenProject>
-    <AssemblyName>Maui.Tizen.Core.RefPackCompile</AssemblyName>
+
+    <!--
+      Deliberately the REAL product assembly name, not a lane-specific one. The sample lane
+      references this project, and the point of that reference is to reproduce what a consumer sees
+      when they reference the Maui.Tizen.Core package. Referencing something called
+      "Maui.Tizen.Core.RefPackCompile" would exercise a boundary that does not exist in the product.
+    -->
+    <AssemblyName>Maui.Tizen.Core</AssemblyName>
     <RootNamespace>Microsoft.Maui.Platforms.Tizen</RootNamespace>
 
     <IsPackable>false</IsPackable>
@@ -33,80 +52,44 @@
 
     <EnableDefaultCompileItems>false</EnableDefaultCompileItems>
 
-    <!-- The whole point of this lane: exercise the `#if TIZEN` branches. -->
     <!--
-      TIZEN only. PLATFORM was also defined here but NOT by the product, which meant a future
-      `#if PLATFORM` block would compile in this lane and vanish from the shipping assembly - the
-      exact class of drift this lane exists to prevent. No source uses it today; removed before one
-      does. A test pins the two define sets together.
+      TIZEN only, and it must stay that way. PLATFORM was also defined here but NOT by the product,
+      which meant a future `#if PLATFORM` block would compile in this lane and vanish from the
+      shipping assembly - the exact class of drift this lane exists to prevent.
+      RefPackLaneAndProductDefineTheSameSymbols pins the two define sets together.
     -->
     <DefineConstants>$(DefineConstants);TIZEN</DefineConstants>
   </PropertyGroup>
 
   <!--
     Runs the PublicAPI analyzer over the REAL product sources with the REAL slice baselines.
-    src/Maui.Tizen.Core cannot be built without the Samsung workload, so this is the only lane
-    where RS0016/RS0017 can actually be enforced before that ships.
+    src/Maui.Tizen.Core cannot be built without the Samsung workload, so this is the only lane where
+    RS0016/RS0017 can actually be enforced before that ships.
+
+    ONLY the backend baseline is attached. The sample's baseline belongs to the sample's own
+    compilation, and attaching it here is precisely what made ownership unverifiable.
   -->
   <ItemGroup>
     <PackageReference Include="Microsoft.CodeAnalysis.PublicApiAnalyzers">
       <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
       <PrivateAssets>all</PrivateAssets>
     </PackageReference>
-    <!--
-      The product baseline. This is the one that matters: it is what src/Maui.Tizen.Core itself
-      consumes, and what a reviewer should read to see this package's public surface.
-    -->
+
     <AdditionalFiles Include="$(RepositoryRoot)src/Maui.Tizen.Core/PublicAPI/slice/PublicAPI.Shipped.txt" />
     <AdditionalFiles Include="$(RepositoryRoot)src/Maui.Tizen.Core/PublicAPI/slice/PublicAPI.Unshipped.txt" />
-
-    <!--
-      The sample's baseline, kept separate so the product baseline is not polluted with app types.
-      This lane compiles the sample sources too (so they are type-checked against real TizenFX), and
-      the analyzer sees one merged API surface, hence both files.
-    -->
-    <AdditionalFiles Include="$(RepositoryRoot)samples/Maui.Tizen.Sample/PublicAPI/PublicAPI.Shipped.txt" />
-    <AdditionalFiles Include="$(RepositoryRoot)samples/Maui.Tizen.Sample/PublicAPI/PublicAPI.Unshipped.txt" />
   </ItemGroup>
 
   <ItemGroup>
     <PackageReference Include="Microsoft.Maui.Core" />
-
-    <!--
-      PackageDownload rather than PackageReference: these packages publish no net11.0-compatible
-      assets, so a normal reference fails restore with NU1202. We only want the files on disk.
-    -->
-    <PackageDownload Include="$(TizenReferencePackId)" Version="[$(TizenReferencePackVersion)]" />
-    <PackageDownload Include="Tizen.UIExtensions.NUI" Version="[$(TizenUIExtensionsPackageVersion)]" />
     <PackageReference Include="Microsoft.Maui.Graphics" />
   </ItemGroup>
 
-  <Target Name="_AddTizenReferenceAssemblies" BeforeTargets="ResolveAssemblyReferences">
-    <PropertyGroup>
-      <_TizenRefPackDir>$(NuGetPackageRoot)$(TizenReferencePackId.ToLowerInvariant())/$(TizenReferencePackVersion)/ref/net8.0/</_TizenRefPackDir>
-      <_TizenUIExtensionsDir>$(NuGetPackageRoot)tizen.uiextensions.nui/$(TizenUIExtensionsPackageVersion)/lib/tizen10.0/</_TizenUIExtensionsDir>
-    </PropertyGroup>
-
-    <Error Condition="!Exists('$(_TizenRefPackDir)Tizen.NUI.dll')"
-           Code="MAUITIZEN0102"
-           Text="Could not find Tizen.NUI.dll under '$(_TizenRefPackDir)'. Expected it from $(TizenReferencePackId) $(TizenReferencePackVersion); run 'dotnet restore' for this project first." />
-
-    <ItemGroup>
-      <Reference Include="$(_TizenRefPackDir)Tizen.NUI.dll" Private="false" />
-      <Reference Include="$(_TizenRefPackDir)Tizen.NUI.Components.dll" Private="false" />
-      <Reference Include="$(_TizenRefPackDir)Tizen.Applications.Common.dll" Private="false" />
-      <Reference Include="$(_TizenRefPackDir)Tizen.Applications.UI.dll" Private="false" />
-      <Reference Include="$(_TizenRefPackDir)Tizen.Log.dll" Private="false" />
-      <Reference Include="$(_TizenRefPackDir)Tizen.dll" Private="false" />
-      <Reference Include="$(_TizenUIExtensionsDir)Tizen.UIExtensions.NUI.dll" Private="false" Condition="Exists('$(_TizenUIExtensionsDir)Tizen.UIExtensions.NUI.dll')" />
-    </ItemGroup>
-  </Target>
+  <Import Project="$(RepositoryRoot)eng/targets/TizenRefPack.targets" />
 
   <ItemGroup>
     <Compile Include="@(MauiTizenPortableCompile)" LinkBase="Backend" />
     <Compile Include="@(MauiTizenHandlerCompile)" LinkBase="Backend" />
     <Compile Include="@(MauiTizenPlatformCompile)" LinkBase="Backend" />
-    <Compile Include="@(MauiTizenSampleCompile)" LinkBase="Sample" />
   </ItemGroup>
 
 </Project>