PrismLibrary / Prism

Prism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Xamarin Forms, and Uno / Win UI Applications..
Other
6.35k stars 1.64k forks source link

Unable to Install Prism.Windows package in PCL Library #355

Closed TsengSR closed 8 years ago

TsengSR commented 8 years ago

I am porting an 8.1 project to UWP and migrated the main shared project to UWP so far, but I am havving issue to migrate my UILogic assembly (which contains the ViewModels).

I am running Visual Studio 2015 Community Edition with Update 1 installed. The UILogic assembly is an PCL targeting Windows 8.1 and Windows Phone 8.1.

When I switch the PCL to Windows 10, it just would simply jump back to 8.1, which is my first problem. I can force it to stay on Windows 10, if I also target .NET Framework 4.6. After switching, I try to install the Prims.Core package and it works.

The initial project.json looks like

{ "supports": { "net46.app": {}, "uwp.10.0.app": {} }, "dependencies": { "Microsoft.NETCore": "5.0.0", "Microsoft.NETCore.Portable.Compatibility": "1.0.0", "Prism.Core": "6.1.0" }, "frameworks": { "dotnet": { "imports": "portable-net452+win81" } } }

Next I try to install the Prism.Windows package and it fails with

Prism.Windows 6.0.1 is not compatible with .NETPlatform,Version=v5.0. Some packages are not compatible with .NETPlatform,Version=v5.0. Prism.Windows 6.0.1 is not compatible with .NETFramework,Version=v4.6. Some packages are not compatible with .NETFramework,Version=v4.6. All packages are compatible with UAP,Version=v10.0. Prism.Windows 6.0.1 is not compatible with .NETFramework,Version=v4.6 (win-x86). Some packages are not compatible with .NETFramework,Version=v4.6 (win-x86). Prism.Windows 6.0.1 is not compatible with .NETFramework,Version=v4.6 (win-x64). Some packages are not compatible with .NETFramework,Version=v4.6 (win-x64). All packages are compatible with UAP,Version=v10.0 (win10-x86). All packages are compatible with UAP,Version=v10.0 (win10-x86-aot). All packages are compatible with UAP,Version=v10.0 (win10-x64). All packages are compatible with UAP,Version=v10.0 (win10-x64-aot). All packages are compatible with UAP,Version=v10.0 (win10-arm). All packages are compatible with UAP,Version=v10.0 (win10-arm-aot). Package restore failed for 'App.UILogic'. Package restore failed. Rolling back package changes for 'App.UILogic'.

When I remove the "net46.app": {}, target from the project.json, it looks a bit better

Prism.Windows 6.0.1 is not compatible with .NETPlatform,Version=v5.0. Some packages are not compatible with .NETPlatform,Version=v5.0. All packages are compatible with UAP,Version=v10.0. All packages are compatible with UAP,Version=v10.0 (win10-x86). All packages are compatible with UAP,Version=v10.0 (win10-x86-aot). All packages are compatible with UAP,Version=v10.0 (win10-x64). All packages are compatible with UAP,Version=v10.0 (win10-x64-aot). All packages are compatible with UAP,Version=v10.0 (win10-arm). All packages are compatible with UAP,Version=v10.0 (win10-arm-aot). Package restore failed for 'App.UILogic'. Package restore failed. Rolling back package changes for 'App.UILogic'.

If I remove the "Microsoft.NETCore": "5.0.0", dependency, then I get

Unknown Compatibility Profile: uwp.10.0.app Prism.Windows 6.0.1 is not compatible with .NETPlatform,Version=v5.0. Some packages are not compatible with .NETPlatform,Version=v5.0.

If I let it at 8.0/8.1 target it won't work neither, there I get

Could not install package 'Prism.Windows 6.0.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.6,Profile=Profile32', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

No matter which combinations I did choose, it always failed. I had no issues adding this nugetpackages in the UWP Project. I even copied the project.json from the samples (https://github.com/PrismLibrary/Prism-Samples-Windows/blob/master/AdventureWorks.Shopper/AdventureWorks.UILogic/project.json) and did a project restore.

The assemblies did appear in the References, but I was unable to reference ViewModelBase, which is the base class for my ViewModels.

bartlannoeye commented 8 years ago

Prism.Windows only supports Windows 10 UWP apps and Windows 10 UWP class libraries as a valid profile, thus you will not be able to add it to a PCL.

You could add Prism.Core instead and implement ViewModelBase yourself in the PCL if you want to keep it compatible with Windows 8.1 and WP 8.1.

TsengSR commented 8 years ago

That seems like a design flaw though. My ViewModels require navigation properties, which is implemented in ViewModelBase and hence it would make sense to have the ViewModelBase in the core package, as navigation is applicable to WPF and Silverlight applications too.

The ViewModelBase contains nothing Windows 10 or Windows Phone 8.1 specific in it, forcing us to reimplement the ViewModelBase on our own, would make the ViewModelBase in Prism.Windows obsolete.

It would be nice if it would be moved to Prism.Core. In worst case, the INavigationAware impelemtation would do nothing (when viewModelState is null) or work equally to Windows Phone/Store Apps, as it contains no persistance logic.

How else should we implement navigation Logic into our ViewModel, that's not bound to a certain platform? ViewModels in MVVM have to be decoupled, so we can reuse them in WPF, Silverlight, UWP, Windows Phone/Store Apps, Console Apps and even ASP.NET MVC. Some of these platforms of course don't utilize navigation, so it won't be called. But the ViewModel still needs to implement it, otherwise we have to reimplement the ViewModel for other platforms, kind of beating the original goal of MVVM.

Also what's the reasoning behind this? The Prism for Windows Runtime Framework did had an "ViewModel" class (which seems to be more more less exact implementation of the ViewModelBase) that worked with PCL.

I always disliked the idea, that the Prism for Runtime was a distinct framework (distinct from traditional Prism), rathern than one single framework. When I read that we have to use Prism 6 for UWP I was expecting to have one unifed framework, rather than two like before.

As an addition: The implementation is especially a problem when I intend to use Xamarin to have the possibility to port the App to Android & iOS it makes little sense to have the base class inside the Prism.Windows assembly. Currently I don't see how to have my ViewModels portable & reusable

brianlagunas commented 8 years ago

First it may help if you understand that Prism does not support Win/WinPhone 8.0/8.1, or Silverlight. Those are essentially dead technologies as UWP is the direction of Windows Store dev.

The ViewModelBase is UWP specific in terms of functionality and contents of the class. Prism only supports WPF, UWP, and Xamarin.Forms. Navigation is applicable to other platforms, but each platform handles navigation completely different, so each platform must have it's own navigation service, as well as it's own INavigationAware interface. The only platform that does any of the state session stuff is UWP. So that is the only place ViewModelBase makes sense.

If we were only supporting Windows Store apps then this would be a no brainier, but unfortunately that is not the case. If you are trying to write an app across WPF, Silverlight, Win/WinPhone 8.0/8.1, Console, ASP.NET MVC, and UWP all using the same navigation API, well then Prism probably isn't going to be a solution for you.

Prism has to have a distinct implementation for each platform because each platform is so vastly different. You cannot standardize on one INavigationAware for example. Not unless you start dropping features until you reach the common denominator. Which would probably only be OnNavigatedTo/From(NavigationParameters parameters). Removing all of the session state functionality, which in your case would help you out anyways because you want that stuff.

lock[bot] commented 4 years ago

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.