Can not run Android demo on m3 macos

[Jamlee]

Describe the bug

The Android examples cannot be launched using the command line on macOS and Windows. Errors are reported in both cases.

cd samples/ControlCatalog.Android; 
dotnet build # The execution of 'build' is successful.

dotnet run # It cannot be executed and errors are reported as shown in the subsequent screenshots.

It seems that the problem lies in the compilation of XAML. XAML will modify the obj/Debug/net8.0/Avalonia.Dialogs.dll and place it into obj/Debug/net8.0/Avalonia/Avalonia.Dialogs.dll. However, it is not clear why only the ControlCatalog.Android project reports errors.

on macos m3:

on windows:

To Reproduce

cd samples/ControlCatalog.Android; 
dotnet build # The execution of 'build' is successful.

dotnet run # It cannot be executed and errors are reported as shown in the subsequent screenshots.

Expected behavior

It is possible to run Android directly in the command line just like creating a new Android project.

dotnet new android 
dotnet run

dotnet new android

Avalonia version

11.2

OS

Windows, macOS

Additional context

When launching the Android example through Visual Studio, it can be successfully started. However, I'm not sure what command lines Visual Studio uses behind the scenes to start that Android example.

[maxkatz6]

@Jamlee it seems to be an issue specific to solution dev-projects. ControlCatalog is not a demo project.
Please check https://github.com/AvaloniaUI/Avalonia/blob/master/Documentation/build.md document, and I generally would recommend using "nuke" build at least once.

[Jamlee]

ControlCatalog is not a demo project, but https://github.com/AvaloniaUI/samples/ControlCatalog.Android is. It can be run in Visual Studio, but it cannot be run with dotnet run in the command line. It seems that the msbuild process executed by "dotnet run" is different from that executed by Visual Studio. Look at the following targets, which are from dotnet/8.0.8/libexec/sdk/8.0.108/Microsoft.Common.CurrentVersion.targets.

BuildingInsideVisualStudio Variable perhaps is the key to the problem.

<Target
      Name="ResolveProjectReferences"
      DependsOnTargets="PrepareProjectReferences"
      Returns="@(_ResolvedNativeProjectReferencePaths);@(_ResolvedProjectReferencePaths)">


    <!--
        When building this project from the IDE, just gather the referenced build outputs.
        The IDE will already have built the project, so there's no need to do it again here.


        The ContinueOnError setting is here so that, during project load, as
        much information as possible will be passed to the compilers.
        -->


    <MSBuild
        Projects="@(_MSBuildProjectReferenceExistent)"
        Targets="GetTargetPath"
        BuildInParallel="$(BuildInParallel)"
        Properties="%(_MSBuildProjectReferenceExistent.SetConfiguration); %(_MSBuildProjectReferenceExistent.SetPlatform); %(_MSBuildProjectReferenceExistent.SetTargetFramework)"
        Condition="'%(_MSBuildProjectReferenceExistent.BuildReference)' == 'true' and '@(ProjectReferenceWithConfiguration)' != '' and ('$(BuildingInsideVisualStudio)' == 'true' or '$(BuildProjectReferences)' != 'true') and '$(VisualStudioVersion)' != '10.0' and '@(_MSBuildProjectReferenceExistent)' != ''"
        ContinueOnError="!$(BuildingProject)"
        RemoveProperties="%(_MSBuildProjectReferenceExistent.GlobalPropertiesToRemove)$(_GlobalPropertiesToRemoveFromProjectReferences)">


      <Output TaskParameter="TargetOutputs" ItemName="_ResolvedProjectReferencePaths" Condition="'%(_MSBuildProjectReferenceExistent.ReferenceOutputAssembly)'=='true'"/>
      <Output TaskParameter="TargetOutputs" ItemName="%(_MSBuildProjectReferenceExistent.OutputItemType)" Condition="'%(_MSBuildProjectReferenceExistent.OutputItemType)' != ''"/>


    </MSBuild>


    <!--
        Build referenced projects when building from the command line.
        -->
    <MSBuild
        Projects="@(_MSBuildProjectReferenceExistent)"
        Targets="%(_MSBuildProjectReferenceExistent.Targets)"
        BuildInParallel="$(BuildInParallel)"
        Properties="%(_MSBuildProjectReferenceExistent.SetConfiguration); %(_MSBuildProjectReferenceExistent.SetPlatform);  %(_MSBuildProjectReferenceExistent.SetTargetFramework)"
        Condition="'%(_MSBuildProjectReferenceExistent.BuildReference)' == 'true' and '@(ProjectReferenceWithConfiguration)' != '' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '@(_MSBuildProjectReferenceExistent)' != ''"
        ContinueOnError="$(ContinueOnError)"
        RemoveProperties="%(_MSBuildProjectReferenceExistent.GlobalPropertiesToRemove)$(_GlobalPropertiesToRemoveFromProjectReferences)">


      <Output TaskParameter="TargetOutputs" ItemName="_ResolvedProjectReferencePaths" Condition="'%(_MSBuildProjectReferenceExistent.ReferenceOutputAssembly)'=='true' or '$(DesignTimeBuild)' == 'true'"/>
      <Output TaskParameter="TargetOutputs" ItemName="%(_MSBuildProjectReferenceExistent.OutputItemType)" Condition="'%(_MSBuildProjectReferenceExistent.OutputItemType)' != ''"/>


    </MSBuild>


    <!--
        Get manifest items from the (non-exe) built project references (to feed them into ResolveNativeReference).
        -->
    <MSBuild
        Projects="@(_MSBuildProjectReferenceExistent)"
        Targets="GetNativeManifest"
        BuildInParallel="$(BuildInParallel)"
        Properties="%(_MSBuildProjectReferenceExistent.SetConfiguration); %(_MSBuildProjectReferenceExistent.SetPlatform); %(_MSBuildProjectReferenceExistent.SetTargetFramework)"
        Condition="'%(_MSBuildProjectReferenceExistent.BuildReference)' == 'true' and '@(ProjectReferenceWithConfiguration)' != '' and '$(BuildingProject)' == 'true' and '@(_MSBuildProjectReferenceExistent)' != ''"
        ContinueOnError="$(ContinueOnError)"
        SkipNonexistentTargets="true"
        RemoveProperties="%(_MSBuildProjectReferenceExistent.GlobalPropertiesToRemove)$(_GlobalPropertiesToRemoveFromProjectReferences)">


      <Output TaskParameter="TargetOutputs" ItemName="NativeReference" Condition="'%(_MSBuildProjectReferenceExistent.ReferenceOutputAssembly)' == 'true'"/>
    </MSBuild>


    <ItemGroup>
      <_ResolvedProjectReferencePaths Remove="@(_ResolvedProjectReferencePaths)" Condition="'%(_ResolvedProjectReferencePaths.ResolveableAssembly)' == 'false'" />
      <!--
          Copy OriginalItemSpec to OriginalProjectReferenceItemSpec, so that when ResolveAssemblyReferences
          takes these items and resolves them to ReferencePath, we can still recover the _real_ OriginalItemSpec
          for the unresolved reference items.
          -->
      <_ResolvedProjectReferencePaths>
        <OriginalProjectReferenceItemSpec>%(_ResolvedProjectReferencePaths.OriginalItemSpec)</OriginalProjectReferenceItemSpec>
      </_ResolvedProjectReferencePaths>
    </ItemGroup>


    <!-- Issue a warning for each non-existent project. -->
    <Warning
        Text="The referenced project '%(_MSBuildProjectReferenceNonexistent.Identity)' does not exist."
        Condition="'@(ProjectReferenceWithConfiguration)' != '' and '@(_MSBuildProjectReferenceNonexistent)' != ''"/>


  </Target>

I like nuke and dotnet command lines very much. Although Visual Studio is very convenient, I want to figure out what the differences are between the msbuild in Visual Studio and the msbuild in dotnet. Why can't AvaloniaUI/samples/ControlCatalog.Android be run with dotnet run in the command line but can be run in Visual Studio? Can you help me? 🙏

@maxkatz6

[Jamlee]

@jmacato Can you help me? 🙏

[nickodei]

I got the same error message on Rider as well

[Jamlee]

Finally, after five sleepless nights, I found that the problem stemmed from SkipCompilerExecution = true in dotnet8.0.204/packs/Microsoft.Android.Sdk.Darwin/34.0.143/targets/Microsoft.Android.Sdk.AssemblyResolution.targets. By changing it to SkipCompilerExecution = false, the Android sample can be run on MacOS. The screenshots of the successful running are as follows:

@maxkatz6 Do you have a better solution? Or could you please help consult other Maintainers? Modifying the target file of the SDK is really not an elegant way. If this problem can be solved, MacOS will be able to support the development environments of MacOS, IOS and Android simultaneously. Just by installing the Android plugin on Rider, the development experience on MacOS will be great.

[Jamlee]

i create issue to dotnet/android#9499 too.