Fix noisy missing font fallback logging - #35963
Conversation
Treat missing speculative font candidates as expected fallback misses instead of logging errors, while preserving existing font fallback source behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35963Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35963" |
|
/review -b feature/enhanced-reviewer |
This comment has been minimized.
This comment has been minimized.
|
/azp run |
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
|
@kubaflo I could not test my app, but I could test related issue #24059 and I still get the error. Here is the test app with the 35963 PR included. Save and run on Android. |
|
@rokmeglicbit did you test with this: #35963 (comment) ? |
|
@kubaflo yes, it is in the zip project above, the include reference is 35963 Please download .zip and try it yourself. Maybe I did something wrong :( |
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
|
Probably already mitigated/fixed by #33919 lets wait for that to land and see if we then still need to do anything here. |
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
|
@jfversluis did you try the testing and it works? I guess issue 23268 is duplicate of this pull/35963, so testing above .zip would also confirm issue 23268? |
|
@rokmeglicbit I think #33919 is part of SR10, so please see if that make this better. This one (35963) wasn't really a fix but rather making the logging less noisy. Which can still be useful, but the actual root of the issue was the font not being found which is fixed by 33919. The latter is merged and should be available now, making the need for the fix in this issue less needed. Test it out and let me know. I typically don't see pings on closed issues, I get enough notifications as it is, but for this one please feel free to reach out to me directly. My email should be on my GitHub profile. Thanks! |
|
If this helps.
|
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. Fixes #23268 Fixes #33092 - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…tputs are deleted (#33919) <!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change The Resizetizer copies and registers `MauiFont` / `MauiSplashScreen` assets during the build. Two incremental-build gaps could leave an app packaged **without** its fonts or splash screen: 1. **First build (Android/Tizen)** — item *registration* (`AndroidAsset`, `BundleResource`, …) lived **inside** the incremental `ProcessMauiFonts` target. On a clean build the target's output-inference glob was empty, so the platform items were never registered and fonts were missing until a *second* build. The fix splits registration into an always-run `_CollectMauiFontItems` target that maps font paths predictively from `@(MauiFont)`. 2. **Incremental build (all platforms)** — `ProcessMauiFonts` / `ProcessMauiSplashScreens` tracked freshness with `mauifont.stamp` / `mauisplash.stamp` files. A stamp could stay newer than a generated output that was later deleted (partial `obj` clean or concurrent build), so MSBuild skipped the target and the package shipped without the missing font/splash. The fix replaces stamps with `mauifont.outputs` / `mauisplash.outputs` manifests. `_ReadMauiFontOutputs` / `_ReadMauiSplashOutputs` run before freshness evaluation, delete the manifest when a listed generated output is missing, and each processor uses the manifest as its sole `Outputs`. This makes only the affected processor rerun without re-stamping unchanged generated assets and unnecessarily invalidating downstream consumers such as Android aapt2. This PR **consolidates** #35962 (closed): it drops the font/splash stamps, adds `ProcessMauiSplashScreensDependsOnTargets`, and de-duplicates fonts by intermediate filename before `CreatePartialInfoPlistTask`, so colliding names (for example an app and a `ProjectReference` both shipping `OpenSans.ttf`) do not emit duplicate `UIAppFonts` entries. The related runtime-side symptom (noisy missing-font fallback logging) is intentionally out of scope here and handled separately in #35963. ### Issues Fixed Fixes #23268 Fixes #33092 ### Tests - `ResizetizerTests.FontsAreCopiedToAndroidAssetsOnFirstBuild` — clean Release build of the `maui` template asserts the font lands in the Android `assets` folder on the **first** build, then an incremental build confirms `ProcessMauiFonts` is skipped while the always-run `_CollectMauiFontItems` still registers the asset. - `ResizetizerTests.BuildRegeneratesFontsAndSplashWhenIntermediateOutputsAreMissing` (macOS-gated) — builds Android/iOS/MacCatalyst template targets, deletes only the generated iOS/MacCatalyst `MauiInfo.plist` files and verifies both font processors rerun and restore them, then deletes generated font/splash folders, verifies recovery, and finally verifies a no-op build skips both processors. ### Validation - A focused MSBuild sequence verified initial generation, no-op skipping, regeneration after deleting a recorded output, and a subsequent no-op skip using the same manifest-invalidation protocol. - The full integration workflow could not complete locally because Android workload installation exhausted the shared disk; the updated Build integration test will validate on CI. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Gerald Versluis <939291+jfversluis@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!
Fixes #28502
Fixes #24059
Related reports: #19774, #17872, #13239. Related to the embedded-font warning symptom in #19804, but not the broader NuGet asset packaging issue there.
Description
This reduces noisy missing-font fallback logging when an unregistered font family is resolved as a platform/system fallback rather than as an app font asset.
OpenSansRegularandSegoe UIon the affected Windows/Android font manager paths.Scope
This PR intentionally covers the proven Windows and Android root causes. iOS/MacCatalyst was investigated separately, but the current tests pass without the fix there, so this PR no longer changes iOS/MacCatalyst font manager behavior or claims an iOS/MacCatalyst fix.
Validation
dotnet build src\Core\tests\DeviceTests\Core.DeviceTests.csproj -f net10.0-windows10.0.19041.0 -p:WindowsPackageType=None --no-restore -v:minimal