MAUI-Android: Should Runtime Identifier only be in the app?


Been having a problem with a 2 part MAUI-Android app where the first project, the app, is the UI, with the second part being the library that the app uses. The library is published to NuGet. Does the library need the RunTimeIdentifiers declaration/s?

About

Created a MAUI Android Phone Video Capture app as one project and resolved all issues to get it functional. Then separated it into 2 proects; the UI and the Video functionality. This was done by copying the first project, making the second a library, removing the UI from the second and removing the video functionality from the first. Then ran into a problem, could reference the lib project from the app using Add-Add Project Reference, in Visual Studio. That is the app used the lib’s csproj to specify the lib. Found that the app build couldn’t find the lib’s DLL. The reference in the app’s cpsproj is

  <ItemGroup>
    <ProjectReference Include="..\MauiMediaRecorderVideolib\MauiMediaRecorderVideoLib.csproj" />
  </ItemGroup>

So used an explicit reference that worked:

    <Reference Include="MauiMediaRecorderVideoLib">
      <HintPath>..\MauiMediaRecorderVideolib\bin\$(Configuration)\$(TargetFramework)</HintPath>
      <Private>True</Private>
    </Reference>

NuGet

Was able to publish the package to NuGet and using just the app project (removing the above link/s from the app’s csproj) and used the NuGet version of the DLL without any explicit notating for the library

More Info

The both projects had specifications for TargetFrameworks and RuntimeIndentifiers of net9.0-android and android-arm64 respectivily. The built lib directory and/or the the folder the app was looking for was a juxtaposition of these. The two were always one moniker different in the last folder.

<TargetFrameworks>net9.0-android</TargetFrameworks>

and

<PropertyGroup Condition="$(TargetFramework.Contains('-android'))">
    <RuntimeIdentifiers>android-arm64</RuntimeIdentifiers>
</PropertyGroup

AI Coding

You can lead a draft horse to water but you can’t make it drink… With AI coding, you ask a question and you get an answer in the context ofthe question. But at times the AI can’t think outside the box. Sometimes its up to you to ask the right question …

Read on (expand to see discussion)…

The GitHub Copilot Discussion

Q. Blue text is queries to GitHub Copilot.
A. Green text is response from GitHub Copilot.

XALNS7028 System.IO.FileNotFoundException: Could not load assembly 'ProjectLib, Version=0.0.0.0, Culture=neutral, PublicKeyToken='. Perhaps it doesn't exist in the Mono for Android profile? File name: 'ProjectLib.dll`
This error (XALNS7028: System.IO.FileNotFoundException) typically occurs when a required assembly is missing or not properly referenced in a Xamarin or .NET MAUI project. Here are some steps to troubleshoot: 1. Check if DLL Exists 2. Ensure Proper Assembly Reference etc

Yes the DLL does exist. The reference from the app project to the lib project is via the lib projects csproj
Thanks for the clarification! Since your app project references the lib project via its .csproj file rather than directly referencing a .dll, let's go through a few key checks to resolve the missing assembly issue.

Nb The lib project NuGet package as published can be referenced by the app
It then goes on and suggests to not reference the DLL both locally and via the NuGet package...D'Oh!

No what I meant is that if I use the NuGet package alome, the lib get linked.
Then my light bulb moment:

Do I need RuntimeIdentifier?
You might need RuntimeIdentifiers depending on your project's requirements....
It then suggests csproj entries to control where it places the DLL

Why then would the lib project not place the dll in that folder
More about constraining the output folder.

When the lib is built using output path the folder it puts it in one deeper..
More of same ...

It appears to me that the two settings in the project file net9.0-android and android-arm64 are getting banged together to create debug_net9.0-android_android-arm64 So android appear twice. Should android be removed from one?
Various red herrings...

Does this make sense: Have the runtimeidentifiers only in the app project?
And then the penny dropped with Copilot:....
Response: Yes!

Resolution

After some analyis and discussion wrt RunTimeIdentifiers:

Q. To GitHub Copilot:

Does this make sense: Have the runtimeidentifiers only in the app project

A. From GitHub Copilot:

Yes, that makes sense! Typically, RuntimeIdentifiers should be specified only in the app project rather than the library project.

Outcome:

The lib’s built DLL is in:

....\artifacts\bin\MauiMediaRecorderVideoLib\debug_net9.0-android

Further from Copilot:

Why RuntimeIdentifiers Should Be in the App Project

  • Libraries are platform-agnostic: The lib project is meant to be compiled and used across multiple platforms. It doesn’t need architecture-specific constraints unless it has platform-specific dependencies.

  • Apps need architecture-specific builds: The app project is responsible for packaging and deploying to a specific runtime (android-arm64, etc.), so it makes sense to define RuntimeIdentifiers there

Artifacts

GitHub Copilot suggested using Artifacts:

Include this in the lib csproj:

<PropertyGroup>
    <UseArtifactsOutput>true</UseArtifactsOutput>
</PropertyGroup>

Then need a Directory.Builds.props file in the lib project root:

<Project>
    <PropertyGroup>
        <UseArtifactsOutput>true</UseArtifactsOutput>
        <ArtifactsPath>$(MSBuildThisFileDirectory)artifacts</ArtifactsPath>
    </PropertyGroup>
</Project>

Further form GitHub Copilot:

Why Artifacts?

  • .NET 8+ automatically centralizes all project outputs when UseArtifactsOutput is enabled.
 TopicSubtopic
   
 This Category Links 
Category:Xamarin Index:Xamarin
  Next: > MAUI-Android
<  Prev:   Video Capture