3 ms·

I'm considering using C# and Avalonia for cross-platform GUI application development but what holds me back at the moment is that I find it hard to evaluate how

I'm considering using C# and Avalonia for cross-platform GUI application development but what holds me back at the moment is that I find it hard to evaluate how much cross-platform this combo actually is, and how dependencies generally work in the ecosystem. I've read about a dozen different confusing .NET and NET Core versions, and it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms. All of it seems to be quite capable, but how Microsoft-centered is it?

topbanana 3y ago
I would go this way for cross platform native UI
- deleted 3y ago
  [deleted]
Hawxy 3y ago
> it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms. As a default rule, any package you see that targets ".NET Standard 2.0" or ".NET 6+" is using the modern SDK and very likely works across all platforms. This will cover the vast majority of open source packages created/updated in the last 5 years. If a package only specifies '.NET Framework' then it'll be windows-only. Modern packages that are tied to a single platform will likely be named as such and will specify a target that locks it to that platform, ie `net8.0-ios16.0` for iOS.
- jonathanstrange 3y ago
  Thanks, that's a super-helpful reply. Do packages with external C / C++ dependencies include binary blobs for platforms or compile them on the fly, or do they need to be configured for each platform? I mostly worried about standard stuff like Sqlite3.
  - Hawxy 3y ago
    > Do packages with external C / C++ dependencies include binary blobs for platforms or compile them on the fly, or do they need to be configured for each platform? They usually bundle them in. For example the SQLite packages are bundled with ~23 different native binaries for all of the platforms it supports, and they'll be output to the right place as part of the build process. There's nothing you need to configure. For licensing or packaging reasons this might not apply to everything (ie ffmpeg).

topbanana 3y ago

I would go this way for cross platform native UI

deleted 3y ago
[deleted]

Hawxy 3y ago

> it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms. As a default rule, any package you see that targets ".NET Standard 2.0" or ".NET 6+" is using the modern SDK and very likely works across all platforms. This will cover the vast majority of open source packages created/updated in the last 5 years. If a package only specifies '.NET Framework' then it'll be windows-only. Modern packages that are tied to a single platform will likely be named as such and will specify a target that locks it to that platform, ie `net8.0-ios16.0` for iOS.

jonathanstrange 3y ago
Thanks, that's a super-helpful reply. Do packages with external C / C++ dependencies include binary blobs for platforms or compile them on the fly, or do they need to be configured for each platform? I mostly worried about standard stuff like Sqlite3.
- Hawxy 3y ago
  > Do packages with external C / C++ dependencies include binary blobs for platforms or compile them on the fly, or do they need to be configured for each platform? They usually bundle them in. For example the SQLite packages are bundled with ~23 different native binaries for all of the platforms it supports, and they'll be output to the right place as part of the build process. There's nothing you need to configure. For licensing or packaging reasons this might not apply to everything (ie ffmpeg).