The plugin does not work in macOS

[ylatuya]

The plugin does not work in macOS.

For projects targeting .NetFramework, looking at the logs, it tries to launch the Avalonia.Designer.HostApp.exe file directly. This won't work since macOS does not recognize it as an executable binary.

/Users/andoni/.nuget/packages/avalonia/0.10.18/buildTransitive/../tools/net461/designer/Avalonia.Designer.HostApp.exe: /Users/andoni/.nuget/packages/avalonia/0.10.18/buildTransitive/../tools/net461/designer/Avalonia.Designer.HostApp.exe: cannot execute binary file

The process to launch should be mono with the path to Avalonia.Designer.HostApp.exe as first parameter.

For projects targeting net6.0 it fails with the following error:

/usr/local/share/dotnet/dotnet exec --runtimeconfig /Users/andoni/***/src/bin/Debug/net6.0-macos/osx-x64/LongoMatch.runtimeconfig.json --depsfile /Users/andoni//***/src/bin/Debug/net6.0-macos/osx-x64/LongoMatch.deps.json /Users/andoni/.nuget/packages/avalonia/0.10.18/buildTransitive/../tools/netcoreapp2.0/designer/Avalonia.Designer.HostApp.dll --transport tcp-bson://127.0.0.1:56055/ --method avalonia-remote /Users/andoni/***/src/bin/Debug/net6.0-macos/osx-x64/LongoMatch.dll
The specified deps.json [/Users/andoni/***/src/bin/Debug/net6.0-macos/osx-x64/LongoMatch.deps.json] does not exist
Process terminated with exit code 129

There is a LongoMatch.runtimeconfig.json but no LongoMatch.deps.json

[ForNeVeR]

The first issue is clear (I don't know if Avalonia supports Mono, but that's not the point; the plugin should call the designer app using the correct runtime anyway).

The second is not so clear. Does it reproduce on a fresh project?

It is possible that the issue is caused by osx-x64 (have you set the target runtime specifically?)

[ylatuya]

The first issue is clear (I don't know if Avalonia supports Mono, but that's not the point; the plugin should call the designer app using the correct runtime anyway).

We are currently using it with mono, so it definitively works :)

The second is not so clear. Does it reproduce on a fresh project?

It is possible that the issue is caused by osx-x64 (have you set the target runtime specifically?)

I will try launching the command manually, but my guess is that net6.0-macos applications can't be launched directly from the output directory from a conversation I had with xamarin-macios's maintainer. They only work running them from the application bundle. En example is calling NSApplication.Init, which DllImport's from __Internal, expecting the API defined in the app bundle. The difference with my case and the default Avalonia project is that Avalonia's app target net6.0 instead of net6.0-macos.

[JayToltTech]

Working fine for me, Ventura 13.2 on Apple M1 Ultra, Rider 2022.3.2, AvaloniaRider 1.0.3.

[ylatuya]

Working fine for me, Ventura 13.2 on Apple M1 Ultra, Rider 2022.3.2, AvaloniaRider 1.0.3.

Is your project targeting net7.0-macos or just net7.0 ?

[timdinh]

My solution had only iOS and Android project so the preview doesn't show up. As soon as i add the desktop project in and build, the preview come up.

[lassebro]

Hi there, we also stumbled upon this problem. We build the application with net7.0-macos as the target framework. In this case the preview does not work. The project is not recognized. In the previewer only "Unable to determine project name" is displayed.

As soon as we build against net7.0 everything works.

We would be very grateful for help.

[ForNeVeR]

Alright, I think I was able to fix the Mono issue, but I've no idea so far what to do about -macos.

Let's start from the steps to reproduce. Do I just take a normal Avalonia app from template, set the target framework to net7.0-macos, and that's it? That's the issue?

[lassebro]

Exactly. You also need to set the OutputType to exe for the build to work.

<OutputType>exe</OutputType>
<TargetFramework>net7.0-macos</TargetFramework>

You must then select Xamarin.Mac as the Run Configuration.

That should be all.

[lassebro]

Hey @ForNeVeR , happy new year!

Have you been able to reproduce the bug yet? We are very interested in finding a solution.

[ForNeVeR]

Not yet. Any help is appreciated. I am interested in two facts:

1. Whether a build in this mode produces a normal managed .NET assembly
2. What assembly does Rider use in this mode (i.e. what gets passed to the previewer)

Also, now I re-read your description and something's very strange. Xamarin.Mac? What?

Normal Avalonia template doesn't have this, I think?

If you build a mobile app with Xamarin, then it's possible it doesn't have any assemblies runnable on your computer, and then it's impossible to preview them of course.

[ForNeVeR]

Can confirm that a project with -macos TFM is not directly runnable (seemingly it is an iOS project or something?), and that's why we can't even detect it in the runnable project list.

The current recommendation is to always have a "normal" project (without an OS suffix) to run on the host to see the preview.

I have also reviewed the UI and to me it seems it currently lists this requirement adequately.

If you know of a way to run Avalonia previewer for a non-executable project, I am open to suggestions. Otherwise, I consider the issue as resolved.

[lassebro]

Hello @ForNeVeR, thank you for investigating this issue further. Unfortunately, our product relies on the functionality of the -macos workload, so we can't stop using it.
However, I'm not very familiar with this topic either, so I can't contribute anything here.

[ForNeVeR]

This is not something technically possible at this point. Avalonia Previewer process requires an assembly that can be directly loaded by .NET runtime in the current environment. There's no way around this restriction, unfortunately.