prismlibrary / prism

Prism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Xamarin Forms, and Uno / Win UI Applications..

Prism

Prism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Xamarin Forms, Uno Platform and WinUI. Separate releases are available for each platform and those will be developed on independent timelines. Prism provides an implementation of a collection of design patterns that are helpful in writing well-structured and maintainable XAML applications, including MVVM, dependency injection, commands, EventAggregator, and others. Prism's core functionality is a shared code base supported in .NET Standard 2.0, .NET Framework 4.6 / 4.7, and .NET6.0/.NET8.0. Those things that need to be platform specific are implemented in the respective libraries for the target platform. Prism also provides great integration of these patterns with the target platform.

Licensing

The Prism Team would first and foremost like to thank all of those developers who have stepped up over the past 4 years with GitHub Sponsors. We are committed to ensuring the longevity and success of the Prism Library. As a result Prism 9.0 is now Dual License. We continue to offer a FREE Community License for the vast majority of our community, while the Commercial License will now be required by larger organizations to help fund and support the development of Prism. We additionally have the Commercial Plus License which grants access to a number of additional support libraries that build on top of Prism as well as a private Discord channel where you can ask questions and interact with the Prism Team.

Build Status

	Status
Full Build
Prism.Core
Prism.Wpf
Prism.Forms
Prism.Uno
Prism.Maui

Support

• Documentation is maintained in the Prism-Documentation repo under /docs and can be found in a readable format on the website.
• StackOverflow: NOTE The Prism Team no longer supports or engages with questions posted on StackOverflow. Questions posted there may or may not receive correct answers.
• For general questions and support, post your questions in GitHub Discussions.
• You can enter bugs and feature requests in our Issues.
• Enterprise Support: If you are interested in Enterprise Support please email the Prism Team at [email protected]

Videos & Training

By watching our courses, not only do you help support the project financially, but you might also learn something along the way. We believe this is a win-win for everyone.

• Introduction to Prism for WPF (NEW)
• Introduction to Prism (Legacy)
• What's New in Prism 5.0
• Prism Problems & Solutions: Showing Multiple Shells
• Prism Problems & Solutions: Mastering TabControl
• Prism Problems & Solutions: Loading Modules Based on User Roles
• Prism Problems & Solutions: Loading Dependent Views

We appreciate your support.

NuGet Packages

Official Prism releases are available on NuGet. Prism packages are also available on the private Commercial Plus Feed which will be updated with each merged PR. If you want to take advantage of a new feature as soon as it's merged into the code base, or if there is a critical bug you need fixed we invite you to purchase the Commercial Plus License to take advantage of these packages.

Core Packages

These are the base packages for each platform, together with the Prism's Core assembly as a cross-platform PCL.

Platform	Package	NuGet	Commercial Plus Feed
Cross Platform	Prism.Core
Cross Platform	Prism.Events
Cross Platform	Prism.Container.Abstractions
Cross Platform	Prism.Container.DryIoc
Cross Platform	Prism.Container.Unity
WPF	Prism.Wpf
Xamarin.Forms	Prism.Forms
Uno Platform and WinUI	Prism.Uno

Container-specific packages

Each supported IoC container has its own package assisting in the setup and usage of that container together with Prism. The assembly is named using this convention: Prism.Container.Platform.dll, e.g. Prism.Unity.Wpf.dll. Starting with version 7.0, Prism is moving to separate packages for each platform. Be sure to install the package for the Container and the Platform of your choice.

WPF

Package	NuGet	Commercial Plus Feed
Prism.DryIoc
Prism.Unity

Xamarin Forms

Package	NuGet	Commercial Plus Feed
Prism.DryIoc.Forms
Prism.Unity.Forms
Prism.Forms.Regions

Uno Platform

Package	NuGet	Commercial Plus Feed
Prism.DryIoc.Uno

A detailed overview of each assembly per package is available here.

Samples

For stable samples be sure to check out the samples repo for the platform you are most interested in.

• Prism for WPF Samples
• Prism for Xamarim.Forms
• Prism for Uno Platform (Coming soon)
• Prism for .NET MAUI (Coming soon)

Contributing

We strongly encourage you to get involved and help us evolve the code base.

• You can see what our expectations are for pull requests here.

prism's Issues

Project Structure Recommendation/Discussion

The discussion on #10 inspired me to open a new issue about the naming/structure of projects and see if I am off on my own island in this regard (yet again smile).

The whole new platform thing is, well, new, so I think we're all learning along here.

I am wondering if it makes more sense to categorize assemblies/namespaces along by technology/concern then platform, resulting in the following pattern:

..

Example: Prism.Unity.Windows

The other implied suggestion here is to use "Windows" in place of Wpf, as (I feel, personally) it is a stronger brand name, and then can also be extended in the case of Windows 10/Universal/One:

Prism.Mef.Windows.Universal or
Prism.Mef.Windows.One

(This is assuming that "Windows One" -- or "All-in-One" as I believe I have seen -- is the new API name being announced at //build.)

Part of the reasoning behind this suggestion is that I feel this is consistent with Xamarin's approach (which I personally will be adopting, as well):
Xamarin.Forms.Platform.

(We would remove "Platform" to make it more succinct).

So in total:
Prism (PCL)
Prism.Windows (WPF Components)
Prism.Forms (Xamarin.Forms Components)
Prism.Unity (PCL)
Prism.Unity.Windows (Unity WPF Components)
Prism.Unity.Windows.One (Unity Windows 10 Components)
Prism.Unity.Forms (Unity Xamarin.Forms Components)
Prism.Mef (PCL)
Prism.Mef.Windows (MEF WPF components)
Prism.Mef.Windows.One (MEF Windows 10 Components)
Prism.Mef.Forms (MEF Xamarin.Forms Components)

The obvious intention/benefit for this design is that:
. - For components with extensibility points.
.. - For implementations/extensions of extensibility points.

Just another thought that's been kicking around my head and had to get it out. :) Thanks for any consideration as always.

Set default ViewModelLocator resolver for Prism.Wpf.Mef

Since the ViewModelLocator was moved into the primary Prism assembly, we need to set the default type resolver for the ViewModelLocator in the Prism.Wpf.Mef bootstrapper.

note: this has already been done in the Prism.Wpf.Unity bootstrapper

Rename PubSubEvents to PrismEvent?

We need the community's input on this issue. We are considering changing the name of the event aggregator's PubSubEvent to PrismEvent to better align with Prism as a product. What are the community's thoughts on this? Should we make the change? Prism 6 for WPF will contain breaking changes in terms of namespaces. So, since we are breaking apps, now would be the time to do it.

What are your thoughts?

DelegateCommandBase.CanExecuteChanged EventHandler seems to get collected and so never fires on Xamarin

This is another odd behavior I'm afraid. What's happening is that when binding a Button.Command property to a DelegateCommand, the EventHandler reference that the DelegateCommandBase registers with the WeakEventHandlerManager gets collected. So, DelegateCommandBase.RaiseCanExecuteChanged() has no effect. Otherwise, I have no idea why it's being collected, but again, this maybe something off with Xamarin.Forms -- I wouldn't be surprised at this point.

Removing the usage of the WeakEventHandlerManager from DelegateCommandBase fixes the problem, but I'm not sure if that's what you're after. It maybe noteworthy that other libraries that provide an ICommand implementation don't use WeakReferences.

Consider the following ViewModel:

public class SignInPageViewModel : BindableBase
{
    private readonly DelegateCommand signInCommand;

    private string email;
    private string password;

    public SignInPageViewModel ()
    {
        this.signInCommand = Workify.Commands.DelegateCommand.FromAsyncHandler (this.ExecuteSignIn, this.CanExecuteSignIn);
    }

    public DelegateCommand SignInCommand {
        get { return this.signInCommand; }
    }

    public string Email {
        get { return this.email; }
        set { this.SetProperty (ref this.email, value); }
    }

    public string Password {
        get { return this.password; }
        set { this.SetProperty (ref this.password, value); }
    }

    private async Task ExecuteSignIn ()
    {
        // Do something
    }

    private bool CanExecuteSignIn ()
    {
        return !string.IsNullOrWhiteSpace (this.Email) && !string.IsNullOrWhiteSpace (this.password);
    }

    protected override bool SetProperty<T> (ref T storage, T value, string propertyName = null)
    {
        if (base.SetProperty (ref storage, value, propertyName)) {
            this.signInCommand.RaiseCanExecuteChanged ();
            return true;
        } else {
            return false;
        }
    }
}

And the following ContentPage:

<?xml version="1.0" encoding="UTF-8"?>
<ContentPage
    xmlns="http://xamarin.com/schemas/2014/forms"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"

    xmlns:prism="clr-namespace:Prism.Mvvm;assembly=Prism.Forms"
    prism:ViewModelLocator.AutowireViewModel="True"

    x:Class="Views.SignInPage">

    <StackLayout>
        <Entry Text="{Binding Email, Mode=TwoWay}" />
        <Entry Text="{Binding Password, Mode=TwoWay}" />
        <Button Text="SIGN IN" Command="{Binding SignInCommand}" />
    </StackLayout>

</ContentPage>

What's supposed to happen is that the Sign In button is enabled as the Email and Password entries are filled out. But this doesn't happen.

InteractionRequest.Raised is null after viewmodel change

I've got a view that's navigated to and each time it is assigned a new viewmodel as datacontext.
The view contains an InteractionRequestTrigger with its SourceObject bound to a property on the viewmodel. Problem is, the binding is not updated when a new DataContext is assigned, resulting in the SourceObject pointing to an old and probably disposed viewmodel and most importantly, the InteractionRequest.Raised property is null, so nothing happens when I want to trigger the InteractionRequest from the current viewmodel.

Types that inherit from BindableBase are not serializable by data contract

Would it be possible too add the [Serializable] and/or [DataContract] attributes to BindableBase? Without that, types that inherit from BindableBase are not serializable by data contract.

[Windows 10 UAP] Suggestion: Implement navigation with SplitView.

Implement navigation using SplitView including:
Building menus dynamically.
Creation of generic menu.
Contextual menu associated with specific View / Views.
Hierarchical menus.
with specific View / Views.
Hierarchical menus.

Add support for other DI containers

Right now, Prism supports Unity and MEF out of the box, but we would love to add support for other containers.

Some containers we should consider adding support for:

• Autofac
• Ninject
• StructureMap
• others?

If you would like to submit support for a container, use the Prism.Mef.Wpf, Prism.Unity.Wpf and Prism.Unity.Forms projects as a guideline. As you can see the naming convention is Prism... The namespace should follow the Prism. convention and not include the platform. For example, if using Autofac, the namespace should be Prism.Autofac.

[Win10 UAP] Unable to cancel navigation

This is an issue on the current Prism for store (Win8/8.1 RT) implementation. Logged considering we're taking it forward to Win10 (after \Build?) and keep it in the current lightweight form. API changes in Win10 might have impact on the logged issue.

The current implementation of Prism for Windows Runtime doesn't allow you to cleanly cancel navigation, while it is supported by the OS. The FrameNavigationService implementation hooks onto the Frame.Navigating event:

_frame.Navigating += frame_Navigating;

The full eventhandler has NavigatingCancelEventArgs as parameter, which enables cancelling the navigation. However, this is not forwarded to the viewmodel.

departingViewModel.OnNavigatedFrom(viewModelState, suspending);

As an extra: OnNavigatedFrom should be named OnNavigatingFrom, as cancellation can still happen.

Add an alternate implementation of InteractionRequest that gives a modal experience more like the Silverlight one

Silverlight had nice built in support for a message dialog that centered on the view and put a transparent overlay over the background. WPF does not have a native experience for that built in, but it can be written without a great deal of difficulty. It would be great to add this as an alternate presentation strategy for InteractionRequest out of the box.

Milestones/ Roadmap for the next version?

It'd be very helpful for some of us who'd like to contribute to know the features that we'd like to add/fix/remove in the next version. May be discuss them as well (like #8) before we actually start implementing new features.

Prism.Forms Navigate fails always (Xamarin Unity)

I've followed Biran Lagunas tutorial for setting up Prism with Unity for my Xamarin Forms app that targets Windows Universal (RT+WP 8.1) and Android.

But any INavigationService.Navigate call always gives NullReferenceException in Prism.Forms.

This is what I did: Added Prism for Xamarin Forms (Prism.Forms 5.6.1-pre1) package; this will only stick to the Windows 8.1 app, but the included references does in fact work with Xamarin PCL Libraries (Profile 111) if I add the Unity 3.5.1405-prerelease package.

In my PCL I then setup a UnityBootstrapper as such:

    public class Bootstrapper : UnityBootstrapper
    {
        protected override Page CreateMainPage()
        {
            return this.Container.Resolve<HomeView>();
        }

        protected override void RegisterTypes()
        {
            // TODO: SettingsViewModel (plugin)
            this.Container.RegisterType(typeof(IDatabaseManager), typeof(DatabaseManager));

            this.Container.RegisterTypeForNavigation<SettingView>(ViewNames.SettingView);
            this.Container.RegisterTypeForNavigation<TimeLogListView>(ViewNames.TimeLogListView);
            this.Container.RegisterTypeForNavigation<TimeLogView>(ViewNames.TimeLogView);
            this.Container.RegisterTypeForNavigation<HomeView>(ViewNames.HomeView);
        }
    }

And init this in my Xamarin PCL App.xaml.cs:

            this.bootstrapper = new Bootstrapper();
            this.bootstrapper.Run(this);

Running the app brings up the HomeView and with the prism:ViewModelLocator.AutowireViewModel="True" attached property HomeViewViewModel is in fact hooked up properly.

But...

If I for example take in INavigationService in my HomeViewViewModel and try to call navigationService.Navigate(ViewNames.HomeView);, I see the View's Init run all well and fine before a NullReferenceException - Object is not set to an instance of an object in Prism.Forms.

Ideas, clues?

Trying to solve this before my presentation on Wednesday 20 may, at our next Xamarin Meetup here in Stockholm.

[Forms] Get rid of the need for INavigationServiceAware

I really want to have the ability to inject the INavigationService through constructor injection, and not have this workaround of having ViewModels implement the INavigationServiceAware interface in order to get the navigation service.

I want to use DI in my ViewModel constructors like I would for any other service.

Notify View-Model when View.Loaded and View.Unloaded events raise.

I think this is a good Idea to notify View-Model when associated View.Loaded/View.Unloaded event raise. Sometimes you (from inside a View-Model) need to know if View is loaded or not. For example when View still not loaded, if you call RegionManager.RequestNavigate it does not works.

1. One idea is using Triggers and notify view model that view is loaded or unloaded.
2. The second Idea is adding two virtual methods (Loaded and Unloaded) to BindableBase and call them when view loaded or unloaded.
3. Or using a behavior, check if View-Model implements an interface like ILoadAware, call Loaded and Unloaded methods properly.
4. Also it can be implemented in ViewModelLocationProvider class.

What's your Idea?

[Win10 UWP] FrameNavigationService:Navigate overload to accept a page type (Type)

When calling the Navigate method I prefer to pass in a strongly typed Type.
Passing in Type.Name could work but that would be kinda silly going from Type to String back to Type.

Modularity

Back on this thread:

http://compositewpf.codeplex.com/discussions/581235

This was said:

Keep in mind, that not every platform has the concept of modularity or composition, and/or does not support it. For example, mobile apps don't support this concept, instead a navigation framework would be needed.

I would like to challenge this statement. Modularity to me is being able to succinctly compartmentalize a portion of an application. It doesn't necessarily need to be something that is loaded dynamically. I think of it is as clean separation of concern... an actual module, or perhaps an application "content" module. I really enjoyed this in Prism 4.1 and utilized it extensively. I was really able to modify the infrastructure around this feature to really build some awesome loading and initialization within my own framework.

What ends up happening is that each "page" (or "section" or "primary screen") turns into a module, and each module has its own configuration (comprised of commands that are executed when the module loads).

I used to have a project on CodePlex that was an outstanding example of this but then completely hosed it when I switched over to Git (and was sure that Silverlight was dead, and my code was no longer of value... D-O-H!). I wish I could show it to you now so you can get an idea of what I am talking about. It was pretty rad. :)

Anyways, having this functionality (outside of the definition provided above) in a cross-platform manner would be pretty useful/valuable.

Forum/Chat Room ?

GitHub isn't really good about this, but it would be cool to get a chat room to discuss items for this project. That way, meanderings, musings, and other unofficial banter don't get created as issues (halo). It is sort of confusing as "Issues" are really the only way to contact owners, and there really needs to be a forum/chat room for this.

I personally prefer forums, but it looks like chat rooms are the only offerings available right now. Here is one that I know of:

https://gitter.im

Removing from, or opting out of registration, in the IRegionNavigationJournal

(This might be related to: #26 ?)

Currently I can find no mechanism for letting view models opt out of registration in a journal or for removing journal entries. The RecordNavigation method on the IRegionNavigationJournal interface can only look at the view's Uri and the navigation parameters, not the ViewModel instance. I have also looked at writing my own IRegionNavigationService, but this class too is unaware of the ViewModel instance.

I have the following use case in which such a scenario would be useful. Consider the following sequence of views:
SomeView -> CreateItemView -> ItemView

Now from the ItemView I would like to 'GoBack' to the SomeView, skipping the CreateItemView.

It would be nice if there was a mechanism that lets ViewModels decide if they wish to be record in the journal or not, possibly via a parameter in NavigatedFrom?

MEFBootstrapper needs to handle/override ConfigureViewModelLocator()

When using MEF the VML it is falling back to the default Reflection code in the ViewModelLocationProvider instead of using the MEF to instantiate the view model class. To follow the pattern of the other DI bootstrappers, the MEFBootstrapper should override the ConfigureViewModelLocator() and also call this method in the MEFBootstrapper.Run() override.

Forms Unity Bootstrapper

Ideally, my vote would be to make the Forms Unity Bootstrapper as much like the WPF version as possible, if possible. For instance, the Logger should be part of the initialization process, in my view.

Also, there is a lot of room for improvement with the guidance provided with Xamarin's initialization. For instance, they do not define their Application object in Xaml, which I think is unoptimal. Here is an example of this in action:
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client/ApplicationDefinition.xaml

You can also see that I define the MainPage defined in the Xaml there, so there is no need to create it during the setup (bootstrapper) phase.

Also consider that I define my bootstrapper in Xaml as well. Here is the WPF version of what I am working on (I am currently building a Xamarin.Forms WPF renderer as a proof-of-concept project):
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client.Application/Setup.xaml

And you can see that this is assigned here:
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client.Application/Application.xaml#L16

The reason I bring this up is that the Bootstrapper has typically had protected or non-public properties, and hinders it from being defined in Xaml. This would be something to be mindful of for design considerations.

Create Project and Item template for Prism.Wpf

We will be looking at creating project template for Prism for WPF. We need to start getting ideas about what kind of project and item templates to make.

Here are some ideas for Project Template:
Stubbed out starter application
Stubbed Module

Item Templates:
UserControl with ViewModelLocator.AutowireViewModel set to true
UserControl with ViewModel and the ViewModelLocator.AutowireViewModel set to true
XAML Module Catalog
App.config Module Catalog

Not sure about the names of these templates. Also, I would love to hear other ideas of templates we should support.

For example, should we provide a base Module class, or a base ViewModel class in our project templates?

Add support for StructureMap

This is being split from Issue #15

Right now, Prism supports Unity and MEF out of the box, but we would love to add support for other containers.

If you would like to submit support for a container, use the Prism.Mef.Wpf, Prism.Unity.Wpf and Prism.Unity.Forms projects as a guideline. As you can see the naming convention is Prism... The namespace should follow the Prism. convention and not include the platform. For example, if using Autofac, the namespace should be Prism.Autofac.

useModalNavigation parameter on INavigationService.Navigate() is always true

Hi I'm writing a mobile app on Xamarin, and I'm having trouble using INavigationService. It seems that no matter how I call INavigationService.Navigate(), the useModalNavigation parameter is true. For example, I'm currently calling it like this:

this.navigationService.Navigate ("SignInPage", useModalNavigation: false);

But I've also tried:

this.navigationService.Navigate ("SignInPage", null, false, true);

And:

this.navigationService.Navigate ("SignInPage", parameters: null, useModalNavigation: false, animated: true);

Is anyone else having this issue? I'm not sure if this is something specific with Xamarin or if it's the way the interface is defined.

Forms Navigation

I know that everything is very fluid at the moment, but I just want to voice my concern with Forms Navigation. I know that you are mimicking the internal navigation code, and that is where I am taking exception (not your implementation). Getting navigation right is very difficult, so I cannot fault them. Much. :) For starters, I would like to see the "animated" boolean that is passed around handled a little bit better. That is something that should be kept track of in the view if possible.

I am not sure if this can even be encapsulated/addressed in Prism's implementation, but I just wanted to voice it now as it is something I am going to bring up on Xamarin's forums once I get my WPF renderer completed.

[Win 10 UWP] Add Unity support

I went ahead and had a first stab at it:
https://github.com/arbsmith/Prism/tree/master/Source/Windows/Prism.Windows.Store.Unity

Are there some technical reasons for not already having it?

[Win10 UAP] Bring IConfirmNavigation(Request) to UWP

I think this is an important navigation feature that is currently missing in the WinRT/Universal branch, certainly for the LOB apps (to be) created on UWP. The way current navigation for RT works and how Prism plugs in, brings some challenges to the table but it can be done.

Client-Specific Library?

I know in this issue we talked about organization:
https://github.com/PrismLibrary/Prism.Wpf/issues/1

Things look really good right now with how the solution is organized. My only concern now is that the core Prism library has client/presentation components in it. That is, the Commands and Mvvm namespace, as well as IActiveAware.

The original ask/intention for this separation (found here) was meant to be designed so that Prism can be used in any application boundary, not just for applications dealing with presentation.

For instance, one can (and I, for one, am intending to) use Prism for server-side applications. That is, eventing, logging, and yes even modularity are all ubiquitous and can be utilized in any application, regardless of where it exists.

My ask here is that the Prism team (at the very least) consider making a Prism.Client (or Prism.Presentation or...?) assembly with client-specific components within it. That way, when we're using the core Prism in another non-presentation application, we're not scratching our heads wondering what a DelegateCommand is doing there (like we did in 4.1, which is why that issue was created in the first place. :) ).

If this makes sense, my ask would also be that the team considers flattening out the namespaces so that all of the components lie at the root level of this assembly (since there would only be about 9 classes in total). Unless of course there are going to be many more classes added to those namespaces, then disregard.

All of this is open to discussion, of course. Just wanting to get it out there so it doesn't fester in my head. :)

Add simpleinjector DI support

Would be great if https://simpleinjector.org/ could be added to the list of supported DIs

PubSub Events

I would really like to see the PubSubEvent maintained as it's own library rather then rolling it into a common Prism library. There are times when this component is very useful on its own with out anything else. My current project is a good example. They are very sold on the Prism event model but have no need for the rest of Prism. This is definitely the case in services

Should animate parameter on NavigationService.Navigate method signature be removed?

After talking to a number of Xamarin.Forms developers, I am finding that controlling the animation during navigation is very rare.

Is this correct? And if so, should we remove the animate parameter from the Navigate method signature?

If we do keep it, should we at least move it to the end of the method signature? Make it the last parameter?

[Win10 UAP] MvvmAppBase should use Api Contract checking instead of conditional compilation

When using the current Prism for Windows Store Apps package 'as-is' to create a Windows 10 UWP app, you'll get a TypeLoadException on SettingsPane in the WP emulators. To fix this, the conditional compilation checks have to be replaced by Api Contract checking (and SDK extensions for Windows Desktop and Mobile have to be added to the UWP project).

if (ApiInformation.IsTypePresent("Windows.UI.ApplicationSettings.SettingsPane"))
{
    SettingsPane.GetForCurrentView().CommandsRequested += OnCommandsRequested;
}
if (ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons"))
{
    HardwareButtons.BackPressed += OnHardwareButtonsBackPressed;
}

Improve ViewModelLocator ViewModel type name convention assumptions

VML currently just blindly appends "ViewModel" to the type name of the View when using the default View to ViewModel type resolution. With the most common convention for naming Views in MVVM in WPF being to have "View" at the end of the type name, this results in the default convention picking XYZViewViewModel for XYZView, which is just wrong.

We need to make the default type name resolution inspect the View type name, and if it ends in View, only append "Model". If not, append "ViewModel" the way it does now.

The default convention will remain easily overridable through the SetDefaultViewTypeToViewModelTypeResolver method.

Add support for AutoFac

This is being split from Issue #15

Right now, Prism supports Unity and MEF out of the box, but we would love to add support for other containers.

If you would like to submit support for a container, use the Prism.Mef.Wpf, Prism.Unity.Wpf and Prism.Unity.Forms projects as a guideline. As you can see the naming convention is Prism... The namespace should follow the Prism. convention and not include the platform. For example, if using Autofac, the namespace should be Prism.Autofac.

Suggestion: Roadmap, Backlog and tasks

So everyone can contribute, it will be great if we could have a roadmap, backlog and tasks (probably after build). We could use https://trello.com/ for visibility.

[Win10 UWP] Changing patterns with {x:Bind}

So {x:Bind} is changing how binding works. {Binding} connects to a context, which at a top most level is a DataContext. {x:Bind} doesn't connect to a context, it connects directly to properties on the host control, and is strongly typed. This means that {x:Bind} can't use DataContext, because DataContext is type object.
Also, as {x:Bind} has much better performance than {Binding} it should be the new default going forward.

With that context, I was just wondering how this should be handled. I mean I know in the short term one could just make a property that returns (IViewModelType)DataContext, and hope it all kind of works out haha. But in the long term, is there a plan for what the IView should look like to accommodate this?

Some thoughts - you could specify the ViewModel Type you're looking for in the IView itself - IView I suppose. And IView could also implement IView, so you can still do the IView checking for AutoWire?

Move mocks of Prism.Unity.Wpf.Tests to shared library

While having a go at adding support for Autofac (issue #16), I ran into BootstrapperFixtureBase which has a //todo to move to a shared DLL. Together with this class, all mocks for these tests can be shared as well.

Restore Silverlight support

Prism 4 had Silverlight support that was dropped with Prism 5.
It will be not very hard to restore its support. We need for it:

• Enable Silverlight 5 on Prism (Portable) project settings.
• Add reference to Microsoft Async nuget package.
• Resolve little api difference in working with Type/TypeInfo and some other types (there will be total 6 files with few changed lines)
• Add new project - something like Prism.TypeForwarder, that will define System.Windows.Input.ICommand type. We will need prepare three different implementations of this project - one for design time and two for Silverlight/NonSilverlight which will have TypeForwardedToAttribute with redirection to proper assembly.

If there is any chance that it will be accepted, I'll prepare PR for review.

Suggestion: Provide ValidateableBindableBase for WPF

I like the three view model types in Prism for WinRT. Unfortunately in WPF we only have BindableBase. Even ViewModelBase is not really needed in WPF, I guess that ValidateableBindableBase would be an appreciated extension.

Add an .editorconfig file

to standardize on tab size and reduce line ending whitespace.

http://editorconfig.org/

Suggestion for creating the root Frame

I'd like to create an overlay on top of the root Frame. Typically, I would do this by creating a UserControl with a Grid, inside of which I could overlay a control on top of the Frame. The following chunk of Prism for Windows Store application code, in MvvmAppBase makes this a difficult task:

protected async Task<Frame> InitializeFrameAsync(IActivatedEventArgs args)
{
    var rootFrame = Window.Current.Content as Frame;
    // Do not repeat app initialization when the Window already has content,
    // just ensure that the window is active
    if (rootFrame == null)
    {
        // Create a Frame to act as the navigation context and navigate to the first page
        rootFrame = new Frame();

What I would rather see is something like this:

protected virtual Frame GetFrame()
{
    var rootFrame = Window.Current.Content as Frame;
    // Do not repeat app initialization when the Window already has content,
    // just ensure that the window is active
    if (rootFrame == null)
    {
        // Create a Frame to act as the navigation context and navigate to the first page
        rootFrame = new Frame();
    }

    return rootFrame;
}

protected async Task<Frame> InitializeFrameAsync(IActivatedEventArgs args)
{
    var rootFrame = this.GetFrame(IActivatedEventArgs args);

This way, I could still get the base implementation of the Frame logic of InitializeFrameAsync, but I'm able to override the creation of the Frame. While we're at it, let's make InitializeFrameAsync virtual.

[Win10 UAP] Unable to inject own INavigationService

This is an issue on the current Prism for store (Win8/8.1 RT) implementation. Logged considering we're taking it forward to Win10 (after \Build?) and keep it in the current lightweight form. API changes in Win10 might have impact on the logged issue.

The current implementation of Prism for Windows Runtime creates its own INavigationService object in MvvmAppBase.InitializeFrameAsync(). This creation is private and hard-wired to FrameNavigationService. Using your own implementation of INavigationService requires some dirty coding.

private INavigationService CreateNavigationService(IFrameFacade rootFrame, ISessionStateService sessionStateService)
{
    var navigationService = new FrameNavigationService(rootFrame, GetPageType, sessionStateService);
    return navigationService;
}

Suggestion: Split region management and navigation

I know this would be a heavy shift but it might be helpful for futur extensions.

I think that RegionManager currently does to much things at once and violates the SOLID principles. I see especially the Interface Segregation and Single Responsibility Principles are currently violated because it is, for example, quite easy to add your views directly into the views collection of a region and short-circuit the whole navigation concept. Another example is the complex way to use the navigation journal if you want to have a "navigation back" beahvior. A cleaner way would it be to create a NavigationService like we have in the WinRT version. Instead of using the RegionManager or access the NavigationJournal directly, you can just call these methods on the INavigationService interface.

To summarize the advantages of this change:

• Interfaces are easier to understand
• Not that easy to bypass
• Testing is far easier
• Same interface can be used for WPF, WinRT and others.

Suggestion: Merge extension methods into interfaces

Prism for WPF has a big issue when it comes to unit testing. Various important methods like RegisterViewWithRegion and RequestNavigate are provided as extension methods. That makes it unnecessarily hard to create fake objects. At least the navigation is something you might want to test within your view models to see if the correct target is selected.

Official WinForms support

How about adding official WinForms support?

Thoughts on switching unit test framework?

What are the thoughts on switching the unit testing framework away from MS Test, to another more modern framework, such as xunit or fixie?

I should note that the dotnetfoundation projects all seem to be consolidating on xunit.

Call Dispose in RegionNavigationService if View/View Model implements IDisposable

I have checked source code of RegionNavigationService.cs, and It seems there is no such mechanism. I think it would be a good idea to dispose view/view model when IRegionMemberLifetime.KeepAlive is false. This is a good practice to put all clean ups in Dispose method such as unregistering static CompositeCommands or disposing DbContext instance in view model (yes, I'm not a fan of Repository pattern :P).

Start new project with Prism 6?

Next week I will start a new project. Should I use Prism 5 and migrate the project if Prism 6 is released or it is possible to start the project with Prism 6?

Create new XmlnsDefinition standard

When Prism was in Microsoft's hands they used two XmlnsDefinitions:

XmlnsDefinition("http://www.codeplex.com/CompositeWPF", "namespace") -- original
XmlnsDefinition("http://www.codeplex.com/prism", "namespace") - this was meant to replace the original

Now, we should come up with a new schema that is not tied to the codeplex name.

We do have a domain "http://PrismLibrary.com", that has yet to have a site created. So should we use this now?

XmlnsDefinition("http://prismlibrary.com/", "namespace")
XmlnsDefinition("http://www.prismlibrary.com/", "namespace") -- notice the addition of "www"

Other ideas?

ViewModelLocationProvider should use DI instead of Reflection to create instances

I stumbled across this when trying to fit my MEF samples to the Prism 6.0 code base using the ViewModelLocator.AutoWireViewModel . I have a single [ImportingConstructor] for my View Model with one parameter (my business service), but the ViewModelLocationProvider is using Reflection to get the View Model instantiating it with the default constructor. Therefore when the module attempts to display my view, I get this exception. "No parameterless constructor defined for this object." Should the ViewModelLocationProvider be using DI to get the View Model instance instead of Reflection?

[Win10 UAP] INavigationService should provide method to remove items from backstack

This is an issue on the current Prism for store (Win8/8.1 RT) implementation. Logged considering we're taking it forward to Win10 (after \Build?) and keep it in the current lightweight form. API changes in Win10 might have impact on the logged issue.

In Windows 8.1 API the BackStack property was added to the Frame control. The current implementation of Prism for Windows Runtime doesn't expose any way to remove pages from the backstack.