Conditional Code in Base Project

[robloo]

I need to use conditional code in a few places. i.e. #if WINDOWS or #if ANDROID. I must use the preprocessor directives rather than if (OperatingSystem.IsWindows()) because I'm pulling in platform-specific native code that doesn't exist on all platforms.

I thought this would be simple to do... there is lots of documentation on this but it seems there is a lot more to this than what is covered there.

The current Avalonia templates create one "base" project where all of your code exists. I'll call this MyProject.UI. Then it creates platform-specific projects MyProject.UI.Desktop and MyProject.UI.Android, etc. Then I had to convert MyProject.UI.Desktop into something usable which is MyProject.UI.Windows and MyProject.UI.MacOS. Side-note, we should be using the MAUI structure and place all these per-platform projects in a Platforms directory. We also need to use single project for all platforms (except linux) at some point....

Anyway, this default setup simply doesn't support #if WINDOWS type code because the source files are all compiled under the base MyProject.UI assembly. And you know what? They have to be because all the XAML sources avares://MyProject.UI/Controls/ etc. MUST be consistent to compile.

My original plan was to create a shared project will all the source code files. Using this .projitems and Directory.Build.props and Directory.Packages.props it's actually pretty straightforward to manage separate csproj files for every platform. Then I get full access to customization and all the conditional code features just work... but I can't do this because of all the XAML sources which require a consistent assembly.

How are other people solving this?

I get the impression most have only used a single desktop csproj shared across mac/linux/windows and haven't encountered this quite yet.

[maxkatz6]

Generally, different solutions are:

1. Use APIs that compatible with shared target (not possible in your case).
2. Use "interface in shared project + implementation in the platform project" approach. Verbose, but always works.
3. Make shared project multitarget. It doesn't have to be a single "net8.0" project. You can multitarget it, add one or more platforms - i.e. shared project can target "net8.0;net8.0-windows", where "windows" one is only used for MyProject.UI.Windows, while keeping shared for the rest.
4. Similar to #3, but introduce a new platform specific yet shared project with multitargetting. Something what I would prefer, keeping UI in the single-target shared project, while still having a single project, where I can put as many preprocessor directives as I want.

Note on #4, you still can build a projects reference tree that looks like

graph TD;
    A["MyProject.Platform (net8.0;net8.0-window)"] --> B["MyProject.UI (net8.0)"];
    B --> C["MyProject.UI.Windows (net8.0-window)"];
    B --> D["MyProject.UI.MacOS (net8.0-macos)"];
    B --> E["MyProject.UI.Android (net8.0-android)"];

Loading

We also need to use single project for all platforms (except linux) at some point....

It's technically possible, since Avalonia 11.2 builds have some targets for that, but I would not recommend yet.
But IDE problems (VS or Rider always forgetting how to run specific targets), .NET SDK problems (one broken or unsupported target == whole project is broken), scalability problems (single startup project is a huge PITA, but having a shared platform specific project, which isn't a startup project, is better).

Using this .projitems and Directory.Build.props and Directory.Packages.props

Not sure if I understood your solution, but it reminds me of Shared Projects and I don't like that.

[maxkatz6]

I have wrote some docs on platform-specific code:
https://docs.avaloniaui.net/docs/guides/platforms/platform-specific-code/dotnet
https://docs.avaloniaui.net/docs/guides/platforms/platform-specific-code/xaml

But I don't see if I ever mentioned platform-specific shared projects anywhere, only interfaces+implementation.

[robloo]

Thanks for the list of solutions. I'm still not seeing what I expected though. I'll explain below. Yes, these are some older ideas but it still seems better. If I need to update my thinking too that's ok but I would like to see something easier not more complex.

Full context, I'm writing a WebView... which at some point is going to have to be part of Avalonia itself. We should start another repo for that I think. However, to get it done now I'm just doing it in the app.

In the Xamarin days, and with Uno, it was common to use shared projects exactly for my use case. Since a shared project isn't actually a project/assembly, just a list of source code files, it fits in easily to whatever the host project is. So shared code for all platforms would go in a shared project and could use #if normally. Then we commonly broke source code into WebView.Android.cs or WebView.Windows.cs these files could be conditionally referenced as well so completely excluded except on the platform projects you want.

This all actually made things simpler IMO than what you propose above (although, I'm not entirely sure how multi-targeting can solve this case). The source code looks as below:

MyProject.UI
  Controls
    WebView
      WebView.cs
      WebView.Android.cs
      WebView.MacOS.cs
      WebView.Windows.cs
      NavigationStartingEventArgs
      NavigationCompletedEventArgs

MyProject.UI is a shared project and each of the platform-specific implementation files is wrapped with a #if WINDOWS and #endif at the top/bottom of the source code file (easier than include conditions in the project files)

For all Uno Platform's complexities this was actually pretty straightforward and just worked. It's what Xamarin was doing at the time as well AFAIK.

So I was really hoping something like this was going to be possible with Avalonia. In fact, I still think it might be, I just need to force the Windows/Android/etc. platforms to have one assembly name for the XAML sources. I'll play around with that more as it really is my desired direction to go and I was hoping someone had done it already.

Being able to keep platform-specific code side-by-side (if not in source, in the same directory) is pretty useful. The complexity of what you propose with multiple projects does not seem justified to me.

[robloo]

The Avalonia XAML compiler may not be setup correctly here. I've set:

<AssemblyName>MyProject.UI</AssemblyName>
<RootNamespace>MyProject.UI</RootNamespace>

In all platform projects. It's still telling me "Unable to resolve XAML resource".

[robloo]

@maxkatz6 I gave up with the strategy I was attempting which is what Uno/Xamarin was using at the time. You are correct and the easiest is simply to multi-target.

I ended up going with option number 3 in your list above. This means I went back to the project structure in the default Avalonia templates as well. It works well and I'll get used to it. After configuring all the csproj conditions it's definitely easier than I thought.

Since this is for a WebView, option number 4 would be a good long-term solution as well. Pulling all this out into a Controls.WebView project that itself is multi-targeted makes quite a bit of sense. However, I wanted full flexibility in the base project to do this other places in the future and didn't want to manage a separate project right now.

I'm marking this as the answer, thanks for the help!

[maxkatz6]

With multitargetting, we can support platform specific files and folders. In fact, Platform folder should work already, if you set <AvaloniaSingleProject>true</AvaloniaSingleProject> in the csproj. But only in nightly builds: #9613.

But from the technical perspective, there is a little difference comparing to #if ANDROID directives.

[thevortexcloud]

Personally, I do this somewhat backwards using DI. Which is to say I still leave all the platform specific code in the platform specific projects and then inject it at runtime into the shared project. Most people forget that the "can't share platform specific code" restriction is only a compile time restriction. As such there is nothing stopping you from passing something that implements an interface from your shared code back to the shared code.

This also avoids the hell of using preprocessor stuff (it's far more annoying that it seems).

Also if you are feeling adventurous, in a lot of cases you can actually just reimplement a lot of the functionality yourself that the platform specific TFM implements without all the compile time restrictions (for desktops at least, it's as simple as DllImport in a lot of cases). Which makes code in a lot of cases a lot simpler.

[robloo]

A DI approach would work, yes, but it doesn't fix my use case well. I explained above but I'm actually writing a WebView control and it makes sense to keep all the code together for a control. Yes, I could take a services-type DI approach but that isn't quite what I would expect for a control like this (yes, it's ironic I proposed IMessageDialog, IContentDialog a few days ago...)

This also avoids the hell of using preprocessor stuff (it's far more annoying that it seems).

I seem to be in a minority here but I never had a problem with it. I am very careful in how code is structured and how the preprocessor directives are used though to keep it simple.

Also if you are feeling adventurous, in a lot of cases you can actually just reimplement a lot of the functionality yourself that the platform specific TFM implements without all the compile time restrictions (for desktops at least, it's as simple as DllImport in a lot of cases). Which makes code in a lot of cases a lot simpler.

Yes, I'm aware but I'll just use the native browers of each platform and the APIs they already provide. It keeps things a lot simpler for now.