I am (slowly) venturing in to the world of .Net Core and want to create portable libraries (mostly for shared datatypes) that target .Net Standard. Is there a timeline for releasing a version of Prism.Core that targets netstandard?
Thanks!
This is something that I have not looked into yet. I'm not sure exactly what the benefit would be since the features available in the Prism.dll is really geared towards XAML platforms. I would need to dig into this further, which is going to be a low priority for me right now.
Brian,
Totally fair.
As to the benefit, I keep my datatypes in the shared (PCL) so that I can reference them from a variety of projects. I have a base class (similar to BindableBase) that implements INotifyDataErrorInfo and use ErrorsContainer to help with validation.
That said, I'm not arguing for it to be a higher priority.
Thanks for the quick response.
-Craig
@cmjacobs This is something I have looked into contributing. Ultimately there are a few issues that would have to be addressed.
I believe given time this will be well worthwhile, but it's probably still too soon to introduce .NetStandard. Also I would encourage you or anyone else who would like to see this to chip in your two cents on what API level(s) you believe Prism should target specifically (and why).
@dansiegel I think you are correct in that it may be too soon. .NetStandard seems to still be evolving. My hunch is that for Prism.Core, .NetStandard 1.0 could be targeted and that would provide the greatest level of compatibility but it is also the least rich in terms of API surface.
As @brianlagunas pointed out, Prism is geared toward XAML platforms, so perhaps the upper level libraries (WPF, XF and UAP) would not need to be retargeted, as long as Prism.Core remained compatible. I think I need to better educate myself on the ramifications of .NetStandard.
@cmjacobs There is one other issue I forgot to mention. IMHO the only real area where greater portability would be beneficial would be with Xamarin Forms. So unless you were making the Core Library, Forms Library and at least one of the DI libraries for Xamarin Forms .NetStandard compatible there's not much point as you would just restrict yourself down the line with the other Prism libraries.
Great discussion guys! I think based on the comments in this thread, Prism isn't ready for consideration of .NET Standard. I'm going to close this until .NET Standard evolves more and a benefit is more apparent for making the transition.
I think it would be ready for consideration of .NET Standard. Creating a portable library, you can already convert this portable library to .NET Standard. To use Prism.Core with this portable library a workaround can be done to use Prism.Core. However, it would be better not to need this workaround. I think all what would be needed with Prism.Core is to mark the NuGet package to support NetStandard.
@christiannagel Prism.Core certainly could be converted to .NETStandard... but I'm curious what benefit you believe that would have? Remember there are 3 packages that you need for any project.
1) Prism.Core
2) Prism.{Platform}
3) Prism.{Container}
To the best of my knowledge the first 2 could should be convertible to the new .NETStandard particularly for Xamarin Forms. However I'm not currently aware of any of the supported containers having updated to be .NETStandard compatible so you would just be limited by the Prism.{Container} package anyway.
In my UWP and WPF projects I'm currently just using Prism.Core, together with Microsoft.Extensions.DependencyInjection as the container.
The view-model is in a portable library. I'm no longer using the old portable library type, but the new one with NetStandard.
It also would be great to have direct support for the Microsoft.Extensions.DependencyInjection container from Prism. It's easy to use it directly if just Prism.Core is needed.
@christiannagel Prism.Core certainly could be converted to .NETStandard... but I'm curious what benefit you believe that would have? Remember there are 3 packages that you need for any project.
Prism.Core
Prism.{Platform}
Prism.{Container}
On new projects I and others, try to get platform independent. If we can, we do so. We achieve this for example by moving the model and viewmodel to a PCL. Therefore we only need the Prism.Core reference. There is no need for Prism.{Platform} or Prism.{Container}.
It would be much better if Prism.Core targets .NetStandard so we don't have to mess around with PCL.
As temporary solution I would suggest to provide an additional Prism.Core NugetPackage with .NetStandard support.
I don't see a .NET Standard support coming before the release of .NETStandard 2.0 due to our limited time and different versions in .NET Standard for the different platforms. But feel free to have a go at it.
Nothing will happen until .NETStandard 2.0.
@bartlannoeye
I don't see a .NET Standard support coming before the release of .NETStandard 2.0
@brianlagunas:
Nothing will happen until .NETStandard 2.0.
I'm trying to add System.ComponentModel.Annotations but apparently it only supports .NET Standard, not portable. Is there a different solution to allow DataAnnotations in Prism Xarmain.Forms portable apps?
@weitzhandler Maybe give Portable Data Annotations a shot. I had some issues with it, but maybe it works for you.
@mfe-
Removign WP8.1 & Silverlight changing to profile 44 solved the issue.
But now I want to install a different package that's on .NET standard 1.3. Can I do so with Xamarin (UWP, Droid, iOS) and Prism?
@weitzhandler we're working on getting everything converted over to NetStandard. In the mean time feel free to use the preview templates that use a NetStandard1.4 core project instead of PCL and it all works with the existing 6.3.0 release. You just need to install the nuget with dotnet new. If you need additional help hit me up on the Slack Channel.
@dansiegel
that use a NetStandard1.4
Xamarin's released netstandard target version is 1.2, isn't it?
Xamarin is targeting 1.0 https://github.com/xamarin/Xamarin.Forms/blob/master/.nuspec/Xamarin.Forms.nuspec#L106
I was talking about profile 44/151, which complies to netstandard 1.2.
@weitzhandler ProfileX does not compile to netstandardY... The charts are to help dev's get a better sense of API area and understand compatibility mappings between netstandard and the ever confusing profiles.
I said 'complies'.
netstandard 1.0 will be great.
again the profiles are compatible with netstandard versions... to the best of my knowledge, they are compiled to that profile, and not a netstandard version unless Microsoft has changed the tooling behind the scenes to give us the largest bait and switch of them all ;)
Done!
Is it possible to get NuGets for the 7.0 preview? Are they being built and put somewhere, or must I build from github source and use that?
Trying to get Xamarin Forms with Prism to fit into a .Net Standard/Asp.Net Core world isn't easy :)
There hasn't been anything released. I'm still working on some changes before we do the 7.0 release. Once we have the 7.0 release you should see CI packages on our MyGet feed and official releases/previews on NuGet.
Great discussion guys! I think based on the comments in this thread, Prism isn't ready for consideration of .NET Standard. I'm going to close this until .NET Standard evolves more and a benefit is more apparent for making the transition.
.NETStandard 2.0 has been released, can we reopen this please?
@opcodewriter
@opcodewriter @weitzhandler what is it that you want to reopen about this? Prism already supports .NET Standard. We haven't done a release to NuGet as there are some fixes we need to do to WPF & UWP for the automated builds, but Prism.Core is available on MyGet as a .NET Standard package
@dansiegel
I'm using 6.3 from netstandard, so as I said I have no urge for this. Still would be nice to know it's on the radar. And here's my chance to say thanks for the awesome work!
@weitzhandler there's nothing left to convert to .NET Standard. The MyGet packages are just as stable as any pre-release we would put on NuGet, as I mentioned it is simply the CI builds for WPF/UWP that need to be finished before we do the release.
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.
Most helpful comment
Done!