Prism: GTK via Xamarin Forms is not supported

[lordasgart]

_Originally posted by @dansiegel in https://github.com/PrismLibrary/Prism/issues/1433#issuecomment-386138377_

[lordasgart]

But this also affects GTK projects (and macOS Cocoa apps also I assume).
Now that Xamarin 3 supports all platforms from Android, iOS, Windows, macOS and now also Linux with GTK projects.
Are there any plans for resolving this?

[brianlagunas]

There are no new plans to support GTK at this time. You can rebuild the Prism source code to support your requirements if this is needed.

[AmrAlSayed0]

I am confused about this, Prism doesn't use any platform specific code (I think) so any platform that has an implementation of Xamarin.Forms should run fine with Prism. Though after saying this I feel that the devil is in the details. 😅

[dansiegel]

As I originally answered, we specifically exclude the Navigation namespace in Prism.Core from the net45 target framework. This means that any platform implemented with the "full framework" is not going to work. On the Windows side of things that means WPF, which is intentional on our part because WPF is fundamentally different in the way that you navigate and at this time we feel that you should simply build a native WPF app.

On the somebody wasn't thinking about what they were doing side of things is GTK#. Frankly the GTK# head is what I've used for the VS Mac extension we are shipping. Let me be the first to say that as a "Community Supported" Xamarin Forms backend, it's not production quality. The WPF Backend fits into the same category btw. GTK# suffers from another insane problem here as it requires Mono, and uses a full framework TFM which can lead to problems when you have dependencies which actually call into Windows API's that simply do not exist or are not implemented in Mono.

To clarify for @lordasgart:

But this also affects GTK projects (and macOS Cocoa apps also I assume).

The only affected Xamarin.Forms backends are WPF (intentional), and GTK. iOS, Android, UWP, macOS, Tizen, and even Ooui all work with Prism.

[andygikling]

"...we feel that you should simply build a native WPF app."

I'm working on a project as a single developer - it's hard. We needed to support Android and iOS so I chose Prism and XF because that combination maximizes my time to market with the least effort (IMO). It's working great and at this point there's a lot of business logic and UI's built up.

Now I've been asked to build a new Prism Module in this stack under Windows Desktop and the module needs to interface with National Instruments USB hardware which only has .NET 4.6 assemblies and they will not run in UWP... In fact, I'm seeing this sort of limitation more and more frequently. As soon as your awesome, cross platform modular framework app needs to talk to Windows hardware you're out of luck it feels like. I can't seem to work around errors like "System.EntryPointNotFoundException: 'A library name must be specified in a DllImport attribute applied to non-IJW methods.' when constructing .NET Framework objects that talk to hardware... Thoughts?

Anyway, having a WPF version of my app solves all my problems - targeting UWP really feels like I'm coding for Windows with handcuffs on, especially when I'm in need of an internal tool for a small company who doesn't need the improved security of UWP! I mean, many of these shop PCs run Windows 7! I would love to dynamically load different modules which interface to hardware when running under WPF and many others will too!

If WPF is a "full framework" why wouldn't it be easy to just adapt the XF + Prism UI navigation pattern for that platform? Am I missing something? Can we get more detail here as to why this isn't supported already? Why was this intentionally done exactly?

It seems like progress should be made to support these sorts of things (including GTK) if we want the Prism framework to continue to grow. Also, "not production quality" is just a slanted opinion - especially when you're comparing what quality means to people targeting GTK - not everyone loves Microsoft all the time - we should continue on XF's promises for support GTK, and because Prism is very frequently tooled into XF apps, this is becoming a burden.

Last request, @dansiegel, if I were to build Prism and XF from source to try designing a version that plays nice with the WPF backed, can you please try to take a minute to explain more about what's currently missing (I haven't looked at how the platform backend code works for XF unfortunately)?

Anyone reading this, much appreciated, thanks for your time. Again I love the Prism Framework, I just didn't see this pickle coming when I started my project two years ago...

Thanks

[dansiegel]

@andygikling a couple of things here:

1. Since the Prism team has decided to drop the support for the Template10/Prism merge this has untied our hands.... so in Prism 7.2 you should be able to use the full framework targets of Xamarin.Forms
2. Keep in mind that the Xamarin.Forms core team does not support those targets and so you use them at your own risk. There are a lot of known issues since it's a community support target. That said if you're really hell bent on using WPF/GTK# with Xamarin.Forms just keep in mind you'll find yourself either questioning your life choices or sending PR's to Xamarin.Forms while questioning your life choices.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.