Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WPF] Is there any roadmap about compatibility with .Net Core 3.0 in Prism.Wpf? #1544

Closed
Magentaize opened this issue Sep 14, 2018 · 14 comments · Fixed by #1609
Closed

[WPF] Is there any roadmap about compatibility with .Net Core 3.0 in Prism.Wpf? #1544

Magentaize opened this issue Sep 14, 2018 · 14 comments · Fixed by #1609
Labels

Comments

@Magentaize
Copy link

Microsoft has release a .Net Core 3.0 API compatibility test tool here, by the result, it seems like Prism.Wpf use AppDomain to load modules but Microsoft doesn't want to keep on developing it.

@dansiegel dansiegel added the WPF label Sep 14, 2018
@dansiegel
Copy link
Member

.Net Core 3.0 is still in early enough preview that we haven't had any serious discussions roadmap wise. I know there is still some changes the @brianlagunas is planning for WPF, but I can't say where that lands for .Net Core 3.0. I'll leave this open for now until we can speak more to this issue.

@Magentaize
Copy link
Author

Thanks for you reply. I'm looking forward to Prism's next step.

@MikelThief
Copy link
Contributor

It could be an interesting move. Because Prism can work for forms, maybe it is not that much work to make it avalaible for Core or Standard

@brianlagunas
Copy link
Member

@MikelThief Prism.Forms is completely different than Prism.WPF. The main issue I see is the use of AppDomains, and I don't think that will be supported in Core 3.0.

@brianlagunas
Copy link
Member

brianlagunas commented Sep 24, 2018

I just ran the Core 3 analyzer tool and have confirmed that the AppDomain is not compatible and it is not something that will be supported in Core.

https://blogs.msdn.microsoft.com/dotnet/2018/08/08/are-your-windows-forms-and-wpf-applications-ready-for-net-core-3-0/

This is required to load modules from App.config, xaml files, and directories. Since this is a core usage of module registration, we will have to really think how this can be handled before we can support Core 3.0

@brianlagunas
Copy link
Member

After my conversations with the team at MS, this is not something that will happen anytime soon. I am closing this as it's not even on our radar until this issue can be solved by people smarter than me.

@jkotas
Copy link

jkotas commented Sep 26, 2018

@brianlagunas I would like to work with you on figuring the plan to port AppDomain usage in Prism to .NET Core. Would you mind including me on the conversation you had with the MS folks? (I am MS as well - my email address is on my github profile.)

Do you happen to know the reason why Prism.Wpf inspects the assemblies in separate AppDomain? Is it just a performance optimization to make sure that the app does not hold on the assemblies that it does not need, or is it needed for functionality as well? Other similar component catalogs inspect the assemblies in the same AppDomain, e.g. this is what AspNetCore does: https://github.com/aspnet/Mvc/blob/master/src/Microsoft.AspNetCore.Mvc.Core/ApplicationParts/ApplicationPartFactory.cs. I am wondering whether Prism.Wpf can do the same for .NET Core.

cc @jeffschwMSFT @vitek-karas

@brianlagunas
Copy link
Member

brianlagunas commented Sep 26, 2018

@jkotas I added you to the thread. Prism uses a number of AppDomain methods to actually load assemblies form disk into the appdomain at runtime. An example of this usage can be found in the DirectoryModuleCtalog

https://github.com/PrismLibrary/Prism/blob/master/Source/Wpf/Prism.Wpf/Modularity/DirectoryModuleCatalog.Desktop.cs

You can open up the Prism.WPF solution and Search for AppDomain, and you can find where it is being used, and even test any suggested updates with Core 3.

@brianlagunas
Copy link
Member

After speaking in more detail with MS, we might have a path forward. I'll reopen this issue as it's not completely dead now.

@brianlagunas brianlagunas reopened this Sep 28, 2018
@horseyhorsey
Copy link

I just installed Core 3 and this is the first place I came too.

My heart sank a little whilst half way down reading the comments, but hopefully it can be resolved.

@AwsomeCode
Copy link

Please consider adding support for Xamarin Forms WPF as well.
There are so many Windows 7, Windows 8 and even Windows 10 below fall creator updated machine.
And Microsoft also supporting WPF as well.

@dansiegel
Copy link
Member

@AwsomeCode you really should look again. To be clear Microsoft does NOT support WPF for Xamarin Forms, as noted in their Wiki. The team may contribute here and there but they don’t support it. There is a clear distinction between the two.

@jfichtner
Copy link

Please consider adding support for Xamarin Forms WPF as well.
There are so many Windows 7, Windows 8 and even Windows 10 below fall creator updated machine.
And Microsoft also supporting WPF as well.

@AwsomeCode you really should look again. To be clear Microsoft does NOT support WPF for Xamarin Forms, as noted in their Wiki. The team may contribute here and there but they don’t support it. There is a clear distinction between the two.

Sorry, I realize that Forms WPF is a bit off topic, but this is the only reference to it I can find. Is Prism not designed to work with Xamarin.Forms WPF? Is the fact that it's not supported by Microsoft a key reason that it's not supported?

@dansiegel
Copy link
Member

Actually it had to do with the way that INavigationService was being shared in Prism.Core... in Prism 7.2 we have migrated INavigationService back to Prism.Forms and it is possible to do a Xamarin.Forms WPF application though it's not recommended for a variety of reasons including the fact that it is not an officially supported platform as well as the fact that the way Xamarin.Forms navigation works is very different from how you would want a proper WPF application to work.

@PrismLibrary PrismLibrary locked as resolved and limited conversation to collaborators Oct 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants