How to use WinRT in Avalonia?

[DmitryBorodiy]

Hello, Avalonia community!
I need to use WinRT inside Avalonia app(on Windows only) and at the same time, stay cross-platform. Any suggestions?

Thank you in advance!
If you can please provide code example🙏

[timunie]

1. Add an interface into main project
2. Add a Windows project and other platfrom project
3. Implement the Interface of 1) into each platform project with the needed API

[maxkatz6]

To add to @timunie comment, to access WinRT APIs you can use CsWinRT library.
OR (probably easier) just use specific windows TargetFramework, like <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework> and then you should be able to access APIs from this Windows version. See https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/wpf-plus-winappsdk (it's not limited by WPF)

[DmitryBorodiy]

I can use something like
<TargetFramework>net6.0-windows10.0.19041.0, net6.0</TargetFramework> to run on Linux also? Can you show me example solution or project source code?

[DmitryBorodiy]

I just want to use Windows-specific APIs such as Share Dialog without losing cross-platform ability.

[J0nathan550]

I just want to use Windows-specific APIs such as Share Dialog without losing cross-platform ability.

FluentAvaloniaTheme

[thevortexcloud]

You can use Xamarin essentials for that. It already implements the share dialogue for most platforms.

https://learn.microsoft.com/en-us/previous-versions/xamarin/essentials/share?tabs=uwp

With that said, that is not the way you multi target. Instead you do:

<TargetFrameworks>net6.0-windows10.0.19041.0;net6.0</TargetFrameworks>

When you build the project, it will output assemblies for both targets. The problem with multi targeting (at least with platform specific TFMs) is that you can't have any reference to a platform specific API in your shared code. If you do, every project but the build output for the platform that implements the API will fail. So to get around that you have to use preprocessor stuff to make the code not appear at all in some outputs. Depending on what you are doing you may need to ignore entire classes EG

#if WINDOWS
public class MyWindowsSpecificClass : MyPlatformInterface {
....
}
#endif

MyPlatformInterface? val = null;
#if WINDOWS
val = new MyWindowsSpecifcClass
#endif

if (val != null) {
val.DoThings()
}

On non Windows outputs, the MyWindowsSpecificClass wont even exist. This however can cause other problems, as you also wont get any feedback in your IDE if one of the targets does not build properly until you explicitly switch to looking at it or build it. Because as far as your IDE is concerned, the code does not exist. You will also need to do stuff like that everytime you have a platform specific bit of functionality that uses a TFM specific API. As such, it can quickly grow into a very large, hard to parse, unmaintainable mess. My advice is not to go this way and instead use DI/runtime checks.

However if you use dependency injection you just have to declare an interface in some shared non platform specific project, and implement the interface in the platform specific project. Then inject all the platform specific services at runtime. Which is significantly simpler to manage and debug. There is an example here for implementing DI in a single project:

https://docs.avaloniaui.net/docs/guides/implementation-guides/how-to-implement-dependency-injection

I don't think there is an official guide for multi project DI, although you can use the one I wrote up here as a base (make sure you thread the entire thread, specifically the bit about not using the main method):

#13455 (reply in thread)

[DmitryBorodiy]

I tried to do this, but for some reason it breaks Avalonia itself. After several tries I saw the error, anyway I'll try. Same approach on Uno Platform.

[DmitryBorodiy]

I just want to use Windows-specific APIs such as Share Dialog without losing cross-platform ability.

FluentAvaloniaTheme

Yes, thank you! I know about that but this is only theme and no Windows specific API implementation.

[thevortexcloud]

What's the error?

[thevortexcloud]

You have a comma separated framework list. That is not valid. It should be something like:

<TargetFrameworks>net8.0;net8.0-windows</TargetFrameworks

[J0nathan550]

If you mean by WinUI3 UI, you have to use FluentAvaloniaTheme. It's available in Nuget Packages and has majority of all WinUI3 controls.

FluentAvaloniaTheme

[jp2masa]

Avalonia does not support AnyCPU. You need to use x64/x86/what ever you are actually targeting.

I don't think that's true. I read that PlatformTarget is practically deprecated and the target architecture is defined by RIDs now.

I can't find the reference right now, but this SO answer points in the same direction.

[thevortexcloud]

I did try this the other day, but I was messing around with .NET Framework. So it probably does work different now. But it refused to work properly until I removed Any CPU. I do seem to vaguely recall also having issues with it on modern .NET too, but I have not tried it in a long time. It's mainly a problem due to the platform specific native libraries.

[jp2masa]

I do seem to vaguely recall also having issues with it on modern .NET too, but I have not tried it in a long time. It's mainly a problem due to the platform specific native libraries.

Maybe if you have a .NET dependency that was not built for AnyCPU. But I'm pretty sure that loading native libraries is not limited by platform target on modern .NET, as I've loaded many different native libraries without ever using platform target. There may be some very specific libraries that work differently, though.

[maxkatz6]

Avalonia doesn't really care about PlatformTarget. But WinRT mappings might do.

[DmitryBorodiy]

microsoft/msix-packaging#635

I have some problems with msix packaging and avalonia project which using target framework monikers.