Uno Class Library with non-Windows TFM can't use <Content Include="..."/>

[Arlodotexe]

Current behavior

If you create an Uno Class Library with some code and a small addition to the .csproj:

<ItemGroup>
	<Content Include="**\*.xaml" Exclude="bin\**\*.xaml;obj\**\*.xaml" />
	<Content Include="**\*.cs" Exclude="bin\**\*.cs;obj\**\*.cs" />
</ItemGroup>

This content is included in the build output and can be accessed via StorageFile.GetFileFromApplicationUriAsync() under UWP and WinAppSDK (uap10.0.18362;net6.0-windows10.0.19041.0):

However, under any other TFMs where Uno.UI is used, including netstandard2.0, net6.0-ios, net6.0-macos ,net6.0-maccatalyst, net6.0-android, and older TFMs that don't use NET6, the content is neither included in the final build nor accessible with StorageFile.GetFileFromApplicationUriAsync():

Skia.WPF:

Skia.GTK: (WSL)

Droid:

WebAssembly:

Expected behavior

Behavior should be consistent between all platforms.

How to reproduce it (as minimally and precisely as possible)

Attached is a project with a complete, minimal repro of the issue, and should be ready-to-run assuming you've got the proper dependencies and tooling (.NET 6 / MAUI / VS 2022).

This is the same project used to create the screenshots above.
ConsistentContentIncludeBehavior.zip

Workaround

The only potential workaround is to create a custom MSBuild Target that

1. Checks the head for all referenced projects
2. Checks each referenced project for any usages of <Content Include="..."/>
3. Manually copy the files to the project head's "Assets" folder

Then, modify all of your code to only use the Assets folder.

Works on UWP/WinUI

Yes

Environment

Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia, Uno.WinUI / Uno.WinUI.WebAssembly / Uno.WinUI.Skia

NuGet package version(s)

4.0.11

Affected platforms

iOS, Android, WebAssembly, WebAssembly renderers for Xamarin.Forms, macOS, Skia (WPF), Skia (GTK on Linux/macOS/Windows), Skia (Tizen)

IDE

Visual Studio 2022

IDE version

17.0.5

Relevant plugins

No response

Anything else we need to know?

No response

[michael-hawker]

@Arlodotexe we don't need these to be in a library specifically, but just the head/app output right? (I mean ideally it should work for both, but we don't need to bundle them specifically in a library for our scenario.)

[Arlodotexe]

@Arlodotexe we don't need these to be in a library specifically, but just the head/app output right? (I mean ideally it should work for both, but we don't need to bundle them specifically in a library for our scenario.)

For our scenario, we don't need to bundle content as part of a nuget package, but we do need it accessible via StorageFile.GetFileFromApplicationUriAsync() in the compiled app.

[jeromelaban]

This issue is related to #2502

[michael-hawker]

@jeromelaban @ajpinedam @MartinZikmund wondering if you had any insights on this issue (compared to the library specific one in #2502), since we just need it at the application level.

Is there some easier work-around we can do? We're concerned about switching/using embedded resources as we want to only access these files on demand for WASM vs. trying to load them all at application start. (As there'll be hundreds of files in our scenario for documentation/examples.)

[jeromelaban]

@michael-hawker For now, the only way to fix this is to have Content items injected into the building project at build time. If it's for a local project, create a build.props file that you can reference from the different heads so that the content files can be properly injected at build time. If it's for a nuget package, it's quite similar, but it needs to be registered as a build folder props file.

[jeromelaban]

I've added a more comprehensive workaround in #2502 (comment), so I'll close this issue as a duplicate.