Copy font assets only works at second build

[AlleSchonWeg]

Description

I wondered, why me IconFont was not working in release mode. The font is in Resources\Fonts\ folder referenced in .csproj:

  <!-- Custom Fonts -->
  <MauiFont Include="Resources\Fonts\*" />

I builded the app and deployed it to the simulator but no icon was shown. Hmm, in debug mode it works. So i looked in the obj folder. In Debug\net8.0-android\assets my ttf file was shown. In Release\net8.0-android\assets was no ttf file:

I started deleting obj/bin folders and rebuild. On the first build the assets folder keeps empty but with the second build the folder contains the ttf files and my icon font starts working in release mode:

The screenshots shows the default MAUI App with the included fonts. The behavior is the same.

Steps to Reproduce

1. Create App from VS template
2. Delete obj/bin folders
3. Build Release and look at the assets folder --> folder emty
4. Build again. Folder not empty

Link to public reproduction project repository

No response

Version with bug

8.0.60 SR6

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• Sometimes .ttf files are missing in the application after the apk or aab build (#22806), similarity score: 0.76
• MauiFont not usable if added in MauiLibrary (#21771), similarity score: 0.71
• [Windows] Some icon fonts not working in unpacked apps (#21993), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[AlleSchonWeg]

The same/similar happens in Debug config. I think the users don't notice this because in debug mode the app is usually already installed and the font files are already stored on the device. Or the user rebuild the app multiple times and then the assets are there.

Edit: Perhaps this doesn't happen only with font assets.

[ninachen03]

I can repro this issue on the latest 17.11.0 Preview 2.1 (8.0.60 & 8.0.40)

[Stedy59]

I provided a similar issue/bug report on this months ago...

If you delete the "obj/bin" folders, and compile/deploy the application (debug OR release), it will ALWAYS leave some of your "resources" behind. Sometimes it is a font file, or two... Most of the time, it is the images... And rarely, a file from the "Assets" folder.

You have to compile, deploy, the compile again for it to "collect" all of your resources. It NEVER works on the first try after removing the "obj/bin" folders!

This happens on Android, and Windows...

[jfversluis]

@Stedy59 would you happen to have the issue number for that?

[Stedy59]

@Stedy59 would you happen to have the issue number for that?

I looked and could not find the issue reported. I do remember commenting, such as I did here, on this issue months ago.

The multiple compile/deploy regiment is required if you remove the "obj/bin" folders.

Also, on a side note... Since all of my "controls (15) / core" are in libraries, sometimes changes WILL NOT be included in subsequent builds unless I remove the "obj/bin" folders... I author custom code libraries for Zebra/Honeywell/Data Logic devices (Barcode scanners / RFID / etc.)

[MitchBomcanhao]

@Stedy59 was it this issue?

[Stedy59]

@Stedy59 was it this issue?

It is... Thank you for finding that! Hopefully they will address it this time around!

[MitchBomcanhao]

ok lets ping @jfversluis again as he was the one interested in it :)

[mattleibow]

@ninachen03 (or anyone really) are you able to get a binlog of the build not working properly?

I have been preparing for a demo all week and probably build like 20 brand new projects and they all just worked.

A binlog of a fail and a success will be most helpful.

[ninachen03]

It took me more than an hour, but unfortunately, I only managed to reproduce it once. I will continue to pay attention to this issue and add the log once I collect it.

[AlleSchonWeg]

@mattleibow
I created two binlogs, but i don't want to upload it public.

[jfversluis]

@AlleSchonWeg find my email address on my GitHub profile and send it there or share a link to OneDrive if its too big to attach.

[algostax]

Microsoft Visual Studio 17.10.5
After removing obj/bin directories, rebuild & publish in IDE produces apk without fonts in assets directory.
After 2nd rebuild & publish these files are placed there finally (sometimes 3rd because random publish errors).
So - to be sure - I always compare apk content against the one with previous version, especially assets subdir :)

[AlleSchonWeg]

Hi @jfversluis or @mattleibow
any news about this issue? I didn't receive any feedback after i send the binlogs.
Thx

[algostax]

Seems that using .Net CLI copies the fonts to assets on every publish in contrast to VS IDE
dotnet publish -f:net8.0-android34.0 -c:Release -p:AndroidPackageFormat=apk (... signing args ...)

[janne-hmp]

The issue is most likely because Rebuild command launches design-time build in VS 2022 IDE, which leads to two same build processes running at the same time, causing random sharing violations. By contrast, Build command does not typically cause design-time build to run, hence things work on the second build. Or if you keep Visual Studio closed, and use dotnet build on command line things should work as well. Notably, if Visual Studio is open in the same configuration (e.g. Release) as where you run dotnet build with no-incremental parameter (meaning rebuild), the design-time build still starts and causes sharing violations with the dotnet build process. If you keep Visual Studio closed or in a different configuration (e.g. Debug) than what is used in dotnet build, the dotnet build command should always succeed correctly with all fonts included.